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for the purpose of licendng and support of the FORTH Dpereting 
System and Programming Language, and to supply application 
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A special thanks this month goes to Mr. Larry Forsley and the 
University of Rochester. The majority of this issue comes from 
his efforts and those of his atociate*. While acting as guest edi- 
tor for thia issue of FORTH DIMENSIONS, Mr. Fortley was also 
ctimplUng and editing the proceedings from thU year's FORTH 
conference at the University of Rochester. Even with this 
"double duty," Mr. Forsley has done an excellent job. 

The quality of material we have received from the University 
of Rochester is excellent and greatly encourages me in my plans 
to "de-Californiie" FORTH DIMENSIONS through the use of re- 
gional quPst erfitors. While Mr. Forsley and the University of 
Rochester may be a tough act to follow, t will welcome contacts 
from anyone else (person and/or organization) who would like to 
try guest editing an issue. For your peace of mind, let me assure 
you that production (typesetting, proofing, printing, etc.) will t>e 
handled for you. If yuu think you have what it takes, give me a 
call or drop rne a line. 

You may find that same of thlt lawjc't sections have tiaen re- 
duced is size end/or eliminated. This is a temporary concession 
because of the volume of material we have to publish in this 
issue. Postal costs pi^lbit expending the size of FORTH 
DIMENSIONS to publish ell we receive, so when we have a quan- 
tity of quality material we publish those items that would seem to 
have the greatest reader interest. 

I hope to meet many of yoo at the FIG National Convention in 
Santa Clara, California on November 28th. Meanwhile, 
GO-FORTH ar>d get additional members. 

C. J. Street 
Editor 
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We are heading into some busy times for FIG. By the time you 
get this copy of FORTH DIMENSIONS we'll have completed the 
Mini-Micro Show in Southern California and be deep into the 
details of the FORML Conference and FIG National Convention. 
Remember that the Convention is Saturday, November Z8th at 
the Marriott \ fjtel in Santa Clara, California. Expect to see 
many of you there. 

We've sent out packets to FORTH vendors about exhibiting at 
the FIG National Convention, If you are interested in exhibiting 
and haven't received a packet, call the FIG line and request one; 
(415) Only $50 for a table! 

This issue is the much awaited University of Rochester 
effort. Its packed with useful material. You ought to order the 
l^ceedings of the 19S1 Rochester FORTH Standards Conference. 
It has 378 pages of excellent papers 

"Starting FORTHf by Leo Brodie is available from FIG 

.-....-end replaces "Using FORTH" as the twjok to have 

about the FORTH language. 

Now, a little lecture. We havH condut;ted an unscientific 
survey and found that in many locations there are people who are 
using FORTH and aren't members of the FORTH Interest Group, 
You as a member should work on them to join. All you have to do 

is make a copy of the Order Form and 

have your associates fill in their name and address. If we each 
get one more person to Join we'll have over 5,000 members. Let's 
do it. 

Roy C. Martens 
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FDRTH «M5 THE UNlVERSmT 

Lawrence P. Forsley 
Laboratory for Laser Energetics 
University of Rochester 



Welcome to the wonderful world of 
URTH, or, University of Rochester 
FORTH. URTH was developed asveraJ 

yeai^ ago and hac been used fof many 
applicstions, some of which ere 
documented here. Beginning with the 
1978 FORTH Intematinal Standards 
Conference, held on Catafina, we have 
followed the FORTH standardization 
effort. As a result, the majority of our 
systems are close to being FDRTH-79 
Standard, althoufjh not FIG model. Very 
few papers in this issue will refer to 
URTH. 

The 1981 Rochester FORTH Standards 
Conference wes held at the University. 
The major reason ftw this, ande from the 
delightful weather at that time of yesTt is 
the FORTH activity at the University. 
This work shows up In several divisions and 
departments including the Lhiivernty 
Computing Center; Optics; Physics and 
Astronomy; Chemical Engineering; 
Mechanical Engineering; Department of 
Radiology, Division of Diagnostic Ultra- 
aoundi Department of Cytopathology; 
Electrical Engineering and the Laboratory 
for Laser Energetics. Indeed, we are 
indebted to the original work by Dick 
Berg, who in 1976 wea an assistant profes- 
sor of Physios and Astronomy, for deriving 
the first URTH system} and to Ken 
hlardwiclc, in 1977 was vAth the 

Univerdty Computing Center, for bringing 
up the IBM 360/65 ISO version baaed on 
Dick's work. At this time. Ken, Dick and 1 
ware the only FORTH users at the 
University. 1 believe the narne URTH was 
coined by Ken. although Dick was partial 
to PARTH, for Mike Williams' 
multitasking Intel 9080 FORTH system. 
Unfortunately, Ken and Dick are no longer 
with the University; and Mike's commit- 
ments prevented his authoring a paper. 
However, their work is reflected in the 
material presented here. 

This Issue starts with three overview 

papers. The first paper is mine and covers 
the developmen: of FORTH at the Labora- 
tory for Laser E.nergetlc^j, whicii remains 
the largest university FORTH user. The 
second paper, by Peter Helmers, reflects 
on the uses of FORTH in medical research 
and clinical applications. The third, by 
John Lefor, covers one of th^ more visible 
university FORTH systems: The IBM 303Z 
telecommunications front-end. 

The next three papers demonstrate a 
variety of ways by which FORTH can be 
used to interact with hardware. The first 
paper, by Rosemary Leary and Carole 
Winkler, deals with three methods of using 
mapped memory. A second paper, by Bob 



Keck and me, demonstrates a high level 
internet handler used in plasma physics 
experiments. The third paper in this 
section is by Joe Sawicki, and suggests 
powerful structures for easily and 
efficiently interfacing hardware. 

The last section illustrates the ciffi- 
culty with defining the difierencfc between 
systems end applications. The first paper 
is by Michael McCourt and Rlchad Marlsa, 
and describes a transportable String 
Stack. The second paper is by Alfred 
Clark wid covers a FC^TH-baaed compleic 
arithematlc calculator. The last paper is 
by Greg Cholmondeley and documents a 
microprocessing too! similar to one 
supplied by Signetics. 

These papers have many things in 
common. One example is the difficulty in 
discriminating between users and imple- 
mentors. Bob Keck, a user, worked with 
me to develop a tool for high level inter- 
ri4it handling. Likewise, At Clark, also a 
user, has augmented a floating point 
package with words appropriate to the 
complex plane. The String Stack is clearly 
a system tool. Complex arithmetic is less 
so, and a microprogramming system is 
clearly an application. Or is it? In the 
context of its user, the microprogramming 
words are a system. We seem to be for- 
ever chasing our tail when det errnining a 
FORTH context. But 1 think that this is 
the power of FORTH. 

Another facet is the use of defining 
words used throughout the papers. An 
extension of defining words, Paul 
Bartholdi's TO concept,^ is used in both 
Joe Sawicki's and Greg Cholmonde^y's 
code. Mike MeCourfs 'W corwept^ is 
used by Peter Helmer's to implement the 
TO concept. However, a student, Carole 
Wir^ler, thought that TO complicated 
Uiings unnecessarily, so she doesn't use it. 

This last comment illustrates one of 
the virtues of universities: freedom of 
dissent. Unfortunately, I have found that 
most groups, and many people, using 
FORTH are intolerant of different views. 
During my involvement with FORTH I 
have watched many groups rise to 
ascendency, tout the true way, and then 
be replaced by another group. This has 
been especially true of the FORTH 
Standards effort where Kitt Peak, 
FORTH, Inc., the European FORTH User's 
Groups and FIG have ail played this role. 
But another view Is possible, which is 
more in keeping with FORT!-fs nature. 

M^y of us see FORTH as being a 
system ' of controlled, or directed, 
anarchy. Since every man, or woman, can 
be for himself it is highly idiosyncratic 
and anarchistic in form. Anyone who has 
tried a team approach to FORTH 
programming is familiar with the tendency 
towards a Tower of Babel. On the other- 
hand, people comfort^le with thie 



unstructured environment find both their 
productivity and creativity increased. 
But, some direction must be applied to 
Share code among iiserc. ! .'(■irj'j-st that 
this direction ^ould bs one ot form, and 
not of content. 

It is appropriate to define documenta- 
tion standards which imply a form. But is 
is Inappropriate to state that something 
can be done only one (with the implied 
right) way. However, people who learn 
something by doing it the wrong way 
undwstand much better thm people who 
are told the right way. 

I think an example of this can be found 
in a conversation 1 had with Kim Harris. 
Kim took e>;ception to an earner paper by 
Peter Helmers on Userstacks. I was told 
that the aoproaiji was ■//roiig. Period. Out 
on further disc^L^^slon, 1 found that 1 agreed 
with Kim. The fault was that Peter had 
found only a partial solution to data 
typing, and in a multitasking system his 
technique might be very cumbersome. 
That's fine. Peter Helmers does not use 
multitasking systems, as his systems are 
all dngla us«r. Interrupt/event ^iven. 
thus, it is worth remembering that each of 
us has different, and valid, viewpoints. 

As a major promoter of FORTH at the 
University of Rochester, 1 have tried to 
define an environment conducive to this 
type of interplay. This has resulted in a 
learning environment with many student 
opportunities; and with Leo Brodie's book. 
Starting Forth, and Don Colburn's study 
guide. Going / orM^i we can begin teaching 
vrtth FORTH. Not teaching FORTH, but 
teaching writh it. Four of the authors in 
this Issue are students and three other 
authors teach courses or seminars. If 
FORTH is ever to catch on like Pascal, or 
FORTRAN, then It must begin wlih 
university teaching as those two languages 
did. in five years my present students will 
be in industry, as my first student con- 
tacts already are. A univeristy environ- 
ment coupled with its students' enthusiasm 
and their eventual employment will 
further FORTH more than any seminar 
series or interest gruup. But it will take 
time. 



1. FORTH DIMEI^JSIONS Vol. I No. A and 
Vol, I No. 5. 

2. FORTH DIMENSIONS Vol. I! No. 4 

3. Personal conversation on May 10, 19S1 
prior to the Rochester Conference. 

4. FORTH DIMENSIOTJS Vol. n, rto. 2 

5. Since that paper, Peter has published 
another one, entitled "Alternative 
Parameter Stacks," which can be found 
in the Proceedings of the 1991 
Rochester FORTH Standards t^on- 
ference. 
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FORTH IN LASFR FUSION 

Lawrence P. y orsley 
Laboratory for Laser Energetics 
Univertity of Rochester 

Abattact 

bierttal confinement fusion lesearcti 
using lasers has resulted in the laboratory 
creation of extraordinary conditions of 
temperature and pressure, duplicating 
those found in tlie cores of white dwarf 
stars. The machines which create these 
conditions anJ the diaqnostirs that moni- 
tor them have become increasingly auto- 
mated. The demands of this research have 
forced us to adopt new techniques^ lii<c 
rORTH, for enhancing interactions 
between engineers, physicists and their 
experiments. 

IntroducUort 

Lasers have been used to simulate 
plasma conditions of high density (ap- 
proaching solid) and temperature (over 60 
million degrees) for several years. The 
goal of thesB experiments has been either 
for weapons effect simulation, practiced 
at the national laboratories, or for the 
possible commercial generation of 
power. This latter program has been 
exclijs^vely pursued by the Laboratory for 
Laser Energetics JLLE!) for almost a 
decade. As can be expected, these exper- 
iments have resulted in the development 
of new diagnostics, end these diagnostics, 
in turn, have resulted in riew fields of 
physics. Besides the Laser Fusion Foa^- 
biltty Project, there are research 
programs in: st^picMecond lasers, neno~ 
second X-Ray sources, X-Ray lasers, 
laboratory asttophysicSt and materials 
damage testing. 

These research programs, and the main 
supporting lasers, are highly automated. 
About one half of the computer systems 
on the 24 beam 13 terrawatt infrared 
Omega laser and ail of the computers on 
the single beam Glass Development Laser 
^GOL/ are implemented iri r^RTfH, This 
paper will explore the development of 
FORTIH-Iike languages at LLE. 

The laboratory is also part of the 
College of Engineering of the University 

of Rochester. Thus, there is an important 
interplay between the staffs, and students, 
of LLE and the University. Most of our 
FORTH systems have been partially, or 
totalh', implemented by students from 
chemi^rry^ electrical engineering, physics 
and computer science. Four of the other 
papers m Iftis journal issue have a student 
author who is also a member of LLE. 

Standardization 

LLE was one of the first Laser Fusion 
laboratorim to automate its laser 
systems.^ Wttenever possible, we relied 



upon standard computers, interfaces and 
software. Originaliv, in 1971, we chose 
the Hfiwiett Packard 2100 series com- 
puter, and the RTE (Real Time Executive) 
Operating System with Fortran, Assembler 
«nd Algol. We used the HP backplane for 
our instrument interface. This system ran 
for over five years and 15,000 shots, but 
building a completely automated laser 
with 24 instead of 4 beams required a 
different approach. 

The Hewlett Packard com^jjter Imc!;- 
plane was limited in the number and vari- 
ptv of devices which could be procured 
and attached to it. We overcame this 
difficulty by adopting CAMAC (5). 
CAMAC provided us with a large capacity, 
computer- independent backplane. It was 
also a widely used standard in the nuclear 
physics community with instrumentation 
and interfaces appropriate to our needs 
available from several sources. 

The problems of computer end soft- 
ware standardization were mora diffi- 
cult. Some of our applications were real- 
time, and appeared to require a fast 
interrupt response. In other cases, we 
were interested in direct image digitiza- 
tion and needed a large address space. 
Other requirements suggested the need for 
a powerful multiprogramming operating 
system. Unfortunately, no one computer 
type and operating system supported all cf 
our applications; and yet, with limited 
manpower, it was difficult to support a 
variety of hardware and software. 

Computer languages, inchjding 
FORTRAN, are different from one vendor 
to another, and especially when operating 
system calls were taken into account. The 
problem of software consistency and sup- 
port was not limited to dissimilar com- 
puters, Ehrman (4:16,17) has shown that as 
many as 12 different languages may be 
encountered by a programmer when edi- 
tors, linkers, and loaders ar^ included in 
addition to the programmmg language, 
Therefore, a unifying software approach 
was nee<ied afnong varlcus operating sys- 
tem functions and languages on the same 
and different computers. We did not know 
of the unix System from Bell Laboratories 
{Ilil905-J929> and the 'C' programming 
language of Richie and Stevens (12:1991- 
2019) in However, I had talked vnth 

people at Kitt Peak In 1976 and travelled 
there in the spring of 1977 to see FCKTH 
being used. 

FORTH 

FORTH was originally developed as a 
small, real time operating system for tele- 
scope control and image processing bv 
Moore (8:497-511), (9) and Rather aO:223"- 
240) at ttie Kitt Peak and NRAO facilities 
which are funded by the National Science 
Foundatton. I found three groups at these 
facilities using FORTH; scientists, com- 
puter engineers and technicians. In some 



cases, the scientists were very knowledge- 
able about FORTH, whereas in other 
erases, they only knew s few worda^ I was 
eapecially impre»ed by Dr. Mark Alcott, 
who was, at the time, with Cat Tech and 
was observing on MR AO's 3S foot radio 
telescope, hfe was pleaaed with his ability 
to change the graphics routines and other 
"systems" software while cortinuirnj to 
collect data. Similarly, 1 found many 
technicians programming and writing test 
prograrns. This appeared to make good 
Ki^f. of their time, especially when they 
would bp familiar with a device, like a 
Varian computer disk controller, and did 
not have to explain its function to a pro- 
grammer. Ft hIso fdppoared that many of 
the computer group's staff enjoyed 
FORTH, although there were problems 
with standardization and cttange. I found 
out several years later, talking with Jeff 
Moler, who was then in t^erations at Kitt 
Peek and is now with the Livermore 
Tandem Mirror Experiment, how difficult 
It was to maintain programs in this envi- 
ronment. 

FORTH seemed to have many desirable 
characteristics, and it provided the same 
programming environmerTt on many 
machines. It allowed both very low level 
access to hardware and high level struc- 
tures to shield users from that hardware. 
There was an assembler, a compiler, and 
an interpreter. What we did not know 
then was the care required in documenting 
it, and the tendency to create personal- 
ized applications and words. But, we 
needed a version of FORTH at the Univer- 
sity. 

Dick Berg, an assistant profesur in 
physics end astronomy at the time,* de- 
compiled a Kitt Peak Varian nucleus circa 
1974. He receded it for the National 
Semiconductor PACE microprocessor. 
Ken Hardwick, then with the tJniverity 
Computing Center, used this as a mode! 
for the IBM 360/65 under TSO and Mike 
Williams developed a multitasking version 
on the INTEL 8080. This was the birth of 
URTH, 

We also procurred a version for the 
Zitog Development System from FORTH, 
Inc. at about the same time to demon- 
strate an automated X-Ray spectrometer. 
Although I had a system for the Hewlett 
Packard 2100 fttim Kitt Peek and e "disk- 
less" version from Don Berrien at Prince- 
ton, I decided that we should develop our 
own version based upon the URTH model. 
Ken Hardwick and I did this In late 1977. 
Since then, other members of the Univer- 
sity community and the Laboratory for 
Laser ETnergetics have worked on various 
versions of FORTH for Data General, 
Modcomp, POP 212 and IBM 3032 compu- 
ters. Through the efforts of Mike 
McCourt, originally with the Department 
of Cytopathology and then with LLE, we 
developed a FORTH-79 system. All of 
these were multitasking systems (2i314- 
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518). 

Tha flrtt FORTH applicstions at LLC 
were hardware testbeds. There are two 
distinct phase* in dealing with hardware. 
The first occurs dUring its initial checkout 
and reoccurs when it fails, or you suspect 
it of failing. At this stage, one is con- 
cerned with device and intprfaf^f imple- 
mentation, and it is important to be ablR 
to interactively set and test data and ad- 
dress lines. 

A testbed must be capable of eKer- 
cisinq hardware at a rate of about 1 kilo- 
hertz* Devices which operate in a faster 
time domain will usually be buffered, as 
en example) with transient digitizers. 
Most other devices, such at relays, 
operate in a 10 Hz or slower time 
domain. At a 1 kHz rate, sufficient sam- 
ples can be tak«i from A/D'a and D/A's to 
quickly check their accuracy and range, 
and thereby checkout many parts of a sys- 
tem quickly. 

Several language features are required 
for tests like these. A means must be pro- 
vided to individiially and collectively set 
address and data hnes. There must also be 
a way of repetitively issuing data/ address 
patterns. Often, a hardware problem is 
intermittent, and a test and branch capa- 
bility is necessary to allow lixjpiung until a 
failure occurs. 

Thus, the specification for a testbed 
lenguage grows quite large, with a major 

role occupied by the command processor, 
or text interpreter. Regardless of 
whether the testbed language is imple- 
mented in Fortran, Basic, Pascal or most 
Other programming languages, a substan- 
tia! effort will be spent on the text inter- 
preter. One of the virtues of FORTH is 
that it comes with a generalized text 
interpreter, suitable fe>r testbeds and 
other applications. 

Our FORTH testbed afftUcatlons In- 
eluded; power conditionirtg testbed for 

checking out laser amplifiers; alignment 
testbed for debugging and calibration of 
automated components; and, general 
CAMAC module testing. Other testbeds 
have heert used to develop image pro- 
cessing hardware and software, and one- 
dimensional reticon arrays. 

The laser amplifier testbed was 
developed along the following sdiedule; 

1. October 1977-Ken Hardwick and I 
began writing a FORTH system 
for the HP 2114. 

2. January 1978- The FORTH system 
was completed and CAMAC soft- 
ware started. 



3. March 197S- A Ifls^r amplifier 
testbed was demonstrated. 

4. April 197S- Single laser amplifier 
te^ad was operational at laser 
hardware subcontractor's ute, 
with a duplicate at LLE. 

By April, it was clear that the 
Omega Power CDndiliuning rom- 
pijter would not he a^^^ilat^le uftil 
August, i97H. Since the Depart- 
ment of Energy four-beam mile- 
stone was originally schedijled for 
early September, 1978, this left 
inaufficient time for laser prepar- 
ation. 

5. April 1978- An LLE engineer, John 
Boles, and a consultant with the 
software aiAwtrntractor developing 
the power conditioning software, 
tiegan cover ting the tingle ampli- 
fier te8U>ed to run 4 laser beams 
synchronized with the laser oscil- 
lator. 

6. June 197B- A six beam laser sys- 
tem was operational. 

7. August 1978- Preliminary delivery 
of full 24 beam system which was 
Fartran-bassd. 

B. October 1978- Department of 
Energy Milestone passed. 

There were substantial differences be- 
tween the 24 beam Fortran based system 
and the 6 beam FORTH version. These 
included the lack of an error detecting 
command processor, a graphic display and 
error archiving on disk. However, whereas 
the FORTH version used 16K words of 
memory and a floppy disk, the Fortran 
based system required 196K words of 
memory and a 15 megabyte hard disk. 

This application also made us aware of 
FORTHS compactness and the speed with 
which applications could be developed. It 
is my feeling that this, and several other 
applications, were brought up in one half 
the time it would have taken in Fortran, 
including FORTH training time. Once 
good documentation is avaiJable, FORTH 
will prove even better. 

Also, 1 have found FORTH systems to 
be more maintainable than comparable 
Fortran systems, because FORTH uses 10 
times fewer source lines. Some care is 
needed when writing FORTH. Another 
advantage con t» gained by the ease of 
using data base technology when building 
process control systems in FORTH. 

Stftial and Temporal Relation shi p s 

The first phase of dealing with hard- 
ware is over when the hardware works. 
The relati onsnips among devices then 
become important. One can hierarchicaily 



organi?"^ reinted devices into subsystems. 
This hierarchy consists of both spatial and 
temporal relationships among components 
(1), tih The manipulation of these rela- 
tionships requires the development of a 
data-base- like language. My initial work 
with Fortran and RTF, and discussions 
with Ray Helmke and Eric Knobll at the 
Wilson Synchrotron,^ led me to develop 
such a language for process control called 
Maps, because it "maps" relationships 
6:109,110. 

A Map contairied two types of struc- 
tures, or Tags. A tag was either a collec- 
tion of data, or a set of pointers to other 
Tags. The Map contained an inverted list 
of pointers to each tag, so that all tags 
were unique and accessible. Two special- 
ized programs, SETUP and BUILD, were 
developed to manipulate and create the 
initial Maps from text files. About a dozen 
subroutines were developed to allow tags 
to be accessed. Data could then either be 
placed into one or more Tags, or retrieved 
from them. In the Interest of speed, this 
system was receded in assembly language 
and later mlcrocoded on a Hewlett 
Packard 21MX-[: computer. This com- 
puter currently runs the Omega 24 beam 
power conditioning, and was mentioned in 
the Testbed Section of this paper. 

Alternatively, by using the text inter- 
preter and FORTHs capability to define 
arbitrary data structures, several data- 
bese-like systems heve been developed. In 
its simplest form, everything in FORTH is 
an executable data structure. Thus, 
FORTH allows one to define spatial and 
temporal relationships in a simpler, ar>d 
more concise fashion than Maps. In ad- 
dition, It is internally consistent, whereas 
Maps hed Fortran, assembler, microcode 
and operating system interface facets. 

Production Systems 

Once FORTH had proven viable for 
small systems, we decided to Implement 
praihictian systems in it. These systems 
included automated diagnostics as well es 
the laser control systems. The prototype 
Omega 24 beam calorimetry system was 
an example of an early production 
systpm. It used simple, vector like struc- 
tures to contain the addresses, reiat ion- 
ships and values associated witii various 
calorimeters, analog to digital convertors 
and calibrators. It was capable of display- 
ing beam energies and calculeting expo- 
nential fits to the data. 

The Ome^ 24 beam AUgnment System 
Is more complex. It has rwi on en LSI 11/2 
with S CAMAC crates and 3 color dis- 
plays, controlling over 1000 devices. 
Initially, the operators used the FORTH 
text interpreter for all commands and 
queries. One advantage was their ability 
to write new "macros" to setup compli- 
cated alignment procedures mors 
quickly. However, there was a risk asso- 



dated with letting operations' personnel 
directly program the system. Therefore, 

the new Alignment System has a more 

complete command procsssor imple- 
mented in FORTH, but which does more 
error detection than t.hp iimplp tr.xt inter- 
preter. This system a 1^0 u^p!s rhp dpfininc) 
words capability and rias a larce disk resi- 
dent data base for describing components. 
With the advert of thf nornmand proces- 
sor, the system was switched over to an 
LSI 11/23 with mapped memory.^ This 
addition allowed approximately 20 tasks to 
handle various functions, communicating 
via 8 queue-based message protocol. 

The laser beam quality is also impor- 
tant to us. We use streak cameras Inter- 
faced to Princeton Applied Research 
Optical Multidiaimel Analyzers for this 
purpose. The PAR OMA includes a 
FORTH-based LSI 11 for acquisition and 
reduction. As with the early Alignment 
and Calorimetry systems, it is pro- 
grammed directly in FORTH.° UnliUe 
those systems though, this was originaliy 
not a turnkey system provided by software 
engineers, rather was irvcrementally 

developed by ohysicists and students. 

We also use FORTH e>:clusjvely on the 
Glass DeveloprTient Laser '^GDD with simi- 
lar computer systems. A FORTH based HP 
2100 is used for power conditioning and 
interlock! for the main bay and three sur- 
rounding tab oratories. A DEC LSI 11/2 
collects laser and target calorimetry data, 
reduces it) end also maintains a date base 
on disk. A second LSI 11 is used in a PAR 
OMA for p race sang streak camera data. 
This is especially ugnificant ^nce QDL ts 
engaged in converting the infrared light to 
ultraviolet, and the first harmonic IR, a 
second harmonic green and the third har- 
monic, UV are observed with the same 
streak camera. This required a very flexi- 
ble system to allow reduction in a quasi- 
two dimensional mode. Another Hewlett 
Packard 2100 has two video digiti2ers and 
a color graphics unit. It is used for 
determining absolute besm intensity and 
modulation for materials damage testing. 
This system is being converted to a DEC 
LSI 11/2J with an RLQl disk attached. A 
third LSI 11 has been used by a graduate 
stuifent_ta obera've target plasma produced 
X-rays.' Finally, an LSI 11/23 is used 
with the nanosecond X-Ray facility for 
the real time acquisition and reduction of 
2D K-rsy diffraction patterns. Recently, 
this system has had an array processor 
interfaced to it to allow real-time fast 
fourier transforms of sample diffraction 
rings. All of these systems are FORTH 
based, with the automated imaging diag- 
nostics serving as prototypes lar Omega 
diagnostics. 

Conclusian 

Although FORTH was relatively un- 
known, it has made a positive impa:;! on 
the development of systems and instru- 



mentation at LLE. It has allowed the 
computer sytems group to adopt the phi- 
losophy of providing tools to scientists and 
engineers, equipping them to dc a job 
themselves. Sometimes, it was questioned 
whether this was the best use of their 
time; and, for some people, it wasn't. But, 
for the majority of people in GDL, and a 
fair number on the Omegsi systems and 
uther laboratories at LLE, FORTH has 
been a success. 
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Footnotes 

^ The four- beam system. Delta, had 
computer control and monitoring In 

1972. (6:101). 

^ He is now with the Defense Mapping 
Agency in Washingtwii D.C 

' Ken is now with Network Systems Inc., 

in Minneapolis, tviN. 

* Cornell Univerity in the summer of 
1977. This facility is now known as the 
Cornell Electron Storage Ring. 

^ The mapped noomory techniques are 
discussed by Leery end Winkler In the 
"Mapped Memory Techniques in 
FORTHf paper In this issue. 

* PAR purchased this system from 
FORTH, Inc. 

' This is mentioned in Sob Keek's and my 
paper, "A High Level Interrupt Handler 
in FORTH", which can be found in this 
iaaue. 



proceec«ngs of the 

1981 rochester forth stamdaros 
conference: 

Many have been waiting for this con- 
ference proceedings to come out, from 
what was a very interesting, and different 
conference. It was the first conference to 
address the FORTH Standard since the 
Catalina meeting of October 1979. Al- 
thou^ it was suggested that the 
Rochester conference was only a regional 
meeting, altendcos car.e from six coun- 
tries and thirteen states. Also notable, we 
successfully divided papers into serial oral 
sessions one morning and had parallel 
poster sessions that afternoon. This way, 
almost everyone of the seventy partici- 
pants oresented something, and no one 
misseu anything (we think). 

In addition, we added travel sponsor- 
ship this year. The Standard Oil Company 
(Ohio), Friends Amis, Inc., Miller Micro- 
computer Services, and Software Ventures 
contributed over $5^00. This travel fund 
covered partial travel expenses for atten- 
dees from ss far away as l-lawaii, Chile, 
Germany and the Netherlands, and as 
close as California and Kentucky. 

The original call for papers was in 
three major areas: the Standard, floating 
point and files management. These areas 
are well represented in the proceedings. 
In addition, there are sections on Philoso- 
phy, Vocabulary, Multi-tasking and Data 
Acquisition, Data Structures and the 
Future of FORTH. The organization we 
adopted combined poster sessions, oral 
sessions and some material not presented 
at the cunference. There is an entire sec- 
tion devoted to working groups on areas 
like Standards clarification, FORTH tech- 
niques. Floating Point and Files Manage- 
ment. There are 37S pages covering the 
state of FORTH. The Proceedings are 
available for $25. See the FIG Order 
Form, 

For those who are interested, there 
will be another Rochester FORTH Confer- 
ence the third week of May, in 1982. The 
tentative subject area will be Process 
Control and Data Acquisition . We expect 
that there will be subareas dealing with 
microprogramming. FORTH machines, 
personal computing, and the Standard. 
For information, please contact the con- 
ference chairman; 

Lawrence P. Forsley 
Laboratory for Laser Energetics 
250 Em9t River Road 
Rochester. NY 14623 
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IMPLEMENTING FORTH BASEB 
MICROCOMPUTERS AT THE 

uravERsrry of Rochester 

MEDICAL CENTER 

Peter H. Helmers 

bdraduetion 

"The micrtiE nre corning!" Everyone 
has heard this so that it is not unexpected 
that physicians isrid researchers at the 
University of Rochester Medical Center 
ask the question; "How can they be put to 
use?" Over the past four years I've been 
attempting to answer thiis <|iJMtlon by 
assembiing a series of rnicracomputen for 
both research antl dinicat applications. 
These systems are all similar in ttieir use 
of an S*iao bus hardware an^itocture and 
a FORTH software envircvtrnenti Yet they 
differ significantly when it comes to 
specific hardware interfaces) application 
software, and types of system users. 

In this article, I am going to focus on 
both these similarities, and these differ- 
ences ir> microcomputer systems- I arn 
going to start out hy discussing their 
common hardware foundation, and then 
explore peripheral devices unique to each 
system's design. Because the ultitnate 
users of a system have a significant 
impact on application software, I am going 
to try to characterize the types of users I 
have dealt with, and their specific soft- 
ware capabilities and needs. From here I 
will discuss some common software pack- 
ages that were written to transcend both 
variable liardwars, and variable user, 
requirements. By discussing all of this in 
terms of how FORTiH has aided system 
development, I hope to fully support my 
contention that FORTfH is an ideal envi- 
ronment to meld many different types of 
users to just as diverse hardware configu- 
rations. 

General h-iardware Organization 

So let's start out by considering the 
common architectural arrangement of 
these microcomputers. They are all Z-SO 
based machines with typical memory sizes 
of from 52K to 48K bytes of static read/ 
write memory and IK to 2K of EPROM 
memory used to contain machine specific 
implementations of commonly needed I/O 
routines such as console and disk drivers. 
Each microcomputer uses one or two eight 
iriu^ :i^fiyi<,' iJui>siLy floppy disk drives. The 
prini,'^!^- system console is comprised of a 
16 line by 6U character memory mapped 
video display along with detached ASCII 
keyboard. Lach machine also has an RS- 
252 serial port for printer hookup. 

These computers are all organized 
armnd the S-100 (eEE-£96> Imjs with from 
ten to fifteen card slots available. With 
the basic setup described above using from 
four to six of these slots, the customiza- 
tion to si>scific system configurations is 



accomplished by a mixture of standard 
commercial snd/or wire-wrapped peri- 
pheral interface cards. Let's consider 
some of these systems in greater detail, 
looking at apecial hardware and how this is 
reflected In the systems* software. 

Ultmaund Dlffnetion Apparaitus (UDA> 

The UDA microcomputer is part of an 
experimental system to explore t!n.' scat- 
tering (diffraction) of medical ultrasound 
signals through tissue samples. The 
scattering is a function of both frequency 
of the ultrasound ngnal (2 to 8 Mhz) and 
the angular position of a receive trans- 
ducer relative to the ultrasound transmit- 
ter. The UDA system thus must control 
tlire« primwy functions: analog carrier 
stqnal generation, tissue sample position- 
ing, and received signal analog process- 
ing. At present, only sampie positioning 
(using stepper motors) is not directly 
handled by the UOA microconnputer. 

Carrier signal gen^iration is controlled 
by means of a Hewlett-Packard i?165A 
programmable signal generator interfaced 
to the microcomputer by means of an 
IE:FE-488 (GP-IH or HP-fFJ) instrumenta- 
\[Ctr\ bui. An Gpto-isolated parallel TTL 
output port is used to control a program- 
mable attenuator on the output of the 
8165A. With a range of to 130 db, the 
attenuator can be used to automatically 
adjust gains for maximum signi*l dynamic 
range. 

The most critical aspect of the UDA 
hardware is the generation of gating 
signals used by the analog processing 
circuitry. This is accomplished by using 
high speed analog mixers driven by digital 
timing circuitry with a resolution of 100 
nsec, and an accuracy of 0.01%. 

Study of Vein Mechanics 

The basis of this system is an experi- 
ment to measure axial force, diameter and 
transmural pressure in a blood vein (in 
vitro) while controlling axial strain and 
pressure. The system consists of a verti- 
cal chamber for the vein specimen, a pro- 
fusion and pressure clamping apparatus, 
force and pressure transducers, and a 
microprocessor for data acquisition. 

The microprocessor contains a sixteen 
channel, twelve bit multiplexed analog to 
digital CA/D) converter to digitize the 
force and pressure signals under higii level 
program control- 
In conjuriction with this A/D is a com- 
mercial video (TV) digitizer capable of 
programmed resolution up to 2*0 lines of 
256 picture elements. The input to this 
digitizer Is from a TV camera aimed at 
the blood vessel under study. A special 
code definition was written to analyze a 
programmable area of the TV image for an 
indication of vessel diameter. This works 



by first threshholding, then detecting 
vessel edges via a software algorithm. By 
using FORTH/Z-eO assembly language, the 
diameter determination executes in leas 
than one second. 

This data acquisition system also con- 
tains a dual modp ^raohi':?: display ^:apabie 
of 123x128x4 grey scale images or 256x 
24C dot graphics. Digitized video images 
use the former mode while acquired pres- 
sure and force data use the dot graphics, 
in addition, the TV signal dynamic range 
can be studied by a dot graphic plot of TV 
signal amplitude versus time. 

Also included In this system, to aid In 
data reduction, is an Advanced Micro 
Devices AM9S11 Mgh speed floating point 
processor IC. This circuit's speed, com- 
bined with the memory mapped graphics 
display, allows real-time analyws and 
display of acquired data, thus glvlrtg 
continuous fee^ack on the progress of the 
experiment. 

Overall, this system replaced a manual 

strip chart and photographic recording 
setup that required several days for data 
collection and analysis. Now data can be 
automaticBjiy acquired and processed 
within a couple of hours. 

Pulmonary Microcomputer 

The pulmonary clinic uses a micro- 
computer Identical to that just described 
except without Uie TV video data ac(}uisi- 
tlon interface. Used in a clinical setting, 
this pulmonary microcomputer Is inte- 
grated with a mass spectrometer and a 
breathing chamber to allow analysis of 
pulmonary tissue volume and capillary 
blood flow. The bfisic procedure requires 
keeping track of the patient's breathing 
(by monitoring volume within the flexible 
breathing chamber) while anal/zing the 
decreasing concentration of two soluble 
gases: dimethyl ether (DM0 and acetylene 
(C2H2), referenced to the concentration 
of an insoluble gas; helium (He). 

The hardware floating point unit facili- 
tates rapid (30 second^ analysis at the 
acquired data, including several curve fit- 
ting operations, and analysis of signals for 
relative maxima/minima. The graphics 
interface allows immediate viewing of the 
acquired data to ascertain proper signal 
levels, and to compare raw data to the 
curve fit data. 

X-Ray Scanning System 

TNs experimental scanner uses a 
slotted wheel and two horizontal slots 
(mounted at 90° to the radial orlentattim 
of the whaeO to achieve a mechanically 
raster scanned X-ray source. The wheel 
and horizontal slots are controlled by 
means of three separate stepper motors 
pulsed under control of the 
microcomputer. X-ray exposure is also 



controlled by the computer o function 
of measured patient X-ray attenuation. 

The microcomputer contains a 
counter/ttmar chip which is used to 
control the stepper motora, a seven 
channel multiplexed eight bit A/0 con- 
verter (used to measure patient X-ray 
attenuation arid X-ray power), and an 
eight bit D/A coiwerter to control the 
exposure time of each X-ray pulse. 
Several digital IfO lines are used to start 
the X-ray rotor, turn on the X-ray genera- 
tor, and control stepper motor direction. 
Other lines are used to sense mechanical 
limit switches. 

The software used in this machine is 
primarily concerned with cnntrcHing 
exptKure time for each X-ray pulse in 
synchrony with the motor movement. The 
system ramps the motora up to speed from 
an initial storied condition. In addition, it 
gradually increases speed to compensate 
for linear speed as the horizontal slots are 
moved radially towards the center of the 
wheels, ''he software also controls expo- 
sure time by sampling the attenuation of 
X-rays through the patient once each 
motor atep, and using table look-up tech- 
niques to set the next pulse's exposure 
time. In addition, total x-ray power is 
sampled and accumulated to keep track of 
total patient dosaqe and X-ray tube usage. 

How User^' Needs Impact These Systems 

In my development of these systems, I 
have encountered three types of users: 
system developers, rfisearcher!;, and physi- 
cians (and their cli'iiL-;^! iL'chniclans). This 
grouping of users also rouqhrly corresponds 
to levete of FORTH software utilizatitn. 
The system developer— myself and pre- 
sumably yourself —is expected to l<now all 
the In's and out's of system operation. If 
something Is missing, it's generally easy to 
add it; this is a primary reason why many 
of us liUe FORTH. However we don't 
actually apply a system, we only set up 
the software foundation for the system. 
As users, we don't count! 

A true end user, whether researcher or 
physician, cannot be sold on FORTH 
because missing capabilities can be easily 
filled in; they don't have the knowledge to 
do so. Nor do they really want to learn to 
do so. They have to be sold on other 
virtues of FORTH. 

In my experience, researchers have 
been very receptive to FORTH In general 
they have aophisticated technical t>ack- 
g rounds but little practical computer 
knowladga. This Is a prime benefit: they 
may have used FORTRAN on a large 
machine for number crunching, but other- 
wise they have few preconceived notions 
about computer organization. They are 
less impressed with structured program- 
ming techniques or file systems than they 
are by the fact that they can physically. 



and interactively, control peripheral 
devices, A research scientist may not 
understand how a word iiiie RAMP or 
SAMPLE works, but can readily learn what 
thay do. 

For example, the FORTH software 
written for the UDA system allows 
explicit user control of the hardware for 
setup purposes as well as automatic con- 
trol during experimental data acquisition 
rur^ Setup can be done through words 
such e« 
(m 25 DB 

{ RPN's a natural here! ) 
m ' FRQ 2500 KHZ" TAUt 

(7ia the gp-ib) 

OK 2.5 USEC CPSRim-OFF 

A data acquisition experiment can be set 

up using Vh^ords such as: 

OK 100 2000 SMEPT-FRBQUaiCV 
{ define control of HPSISSIV > 
OK FIX ED- ATTENUATION 
( define control of atten ) 
0K_ DON'T- SHOW- ATTENUATIONS 
OK 15C0 ^2 NOVR-CONTROL 
( let the minicomputer take 
over control of the micro.) 

In addition, the researcher can build 
upon basic words to create custom appli- 
cation programs as needed. Thus the X- 
ray scanner system can be easily program- 
med by; 

OK MOTOR WHEEL-MOTOR 

( define a 'HOroR' data type) 
OR : ROTkTB-BI 
^ DO 

OK WHEBI>-MOTOR RAMP 

t ramp steppinf iwtora) 

OK UKIT-StriTCHES? 

< sxit loop if motor limited) 

OK SYNCHKONI ZS 

( syr^hroni^e too aotor ptilBe) 

LOOP 

OK > 

A physician or clinical technician is 
much more of an widHtser than the 
researcher. As such, tlMy are less 
concerned with words that allow them 
flexibility in control of peripheral 
hardware; instead they want words that 
control hardware in specific ways towards 
some specified clinical objectives. Thus 
they need to implicitly use both basic 
FORTH words and peripheral driver words, 
but want to only explicitly know words 
that achieve specific aims. But even here 
FORTH can be appreciated. It allows a 
flexible, conceptual system with a non- 
confining syntax. With the pulmonary 
microcomputer, the physician might 
typically have the following dialog: 

CK wmmus calcoiatkshs 
( acquire data, and calc It ) 
CK PRINTBt ^DH RBTOIAS 

( print cesults ) 



OK DME VIEW 

( view plots of gasea on ) 
m C2B2 VIBf 

( ... graphics displity ) 

By teaming a limited, yet full, vocabulary 
of perhaps twenty to fifty well chosen 
words, these non-technlcal users can 
effectively use a FORTH based micro- 
computer with little training or under- 
standing of programming. And without 
fail, they learn to use colon definitions to 
group these basic words to their own 
specific usage patterns. 

Common Software Packages 

As we have just seen, I group FORTH 
software in three coarse categories cor- 
responding to types of users: basic 
FORTH system software, peripheral sup- 
port ext.entions, and custom applications. 
The basic system software does not vary 
at all while custom application software. is 
unique to each end-user system. Peripher- 
al support software is in a hazy area. 
From the point of view of documentation 
end support, any given type of peripheral 
should appear uniform between systems; 
but at the hardware level, each type of 
peripheral varies in myriad details. By 
creating common software packages with 
this in mind I have been able to avoid 
constantly recreating software because of 
hardware variations. 

Common software packages can do 
more than just ease support for similar 
systems. It can effectively hide hardware 
details from the user, thus making dis- 
similar A/D converters, for example. 
^>pear identical from the software point 
of view. And e wall designed set of (friver 
soft wan also imparts increased capabili- 
ties to B system than just those of the 
"raw" hardware. Let's look at a few 
examples of software peripheral dirlvers to 
reinforce these points. 

Many of these microcomputers are 
used for data acquisition purposes involv- 
ing different types of A/D converters and 
real time ciocks. From a hardware point 
of view, some of these A/D's have eight 
bit versus twelve bit resolotions. Some 
have seven or eight analog multiplexer 
channels while others have sixteen. Some 
of the real time clocks have fixed 60 Hz 
resolutions, others are programmable. 

From a conceptual point of view, these 
data acquisition systems all operate 
identically: they can randomly sample 
multiple analog signals at some specified 
rate. The driver software implements 
these concepts uung two words SAMPLE 
and DELAY. SAMPLE takes an integer 
multiplexer channel number as an input 
argument, and returns an integer ampli- 
tude value. It works identically no matter 
what hardware is controlled by it; the 
multiplexer addressing and A/0 digital 
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output format are hidden from the user. 
Similarly, the real time clock works in e 
mariner transparent to hardwnTre 
sprcifins. DFL AY requires only an input 
argument to specify the number of real 
time clock "ticks'* to delay. 

But the conceptual basis of the data 
acquisition package transcends just the 
A/D hardware; there must be some place 
to put the. data. This may be on the para- 
meter Mack, In data arrays, or in disk 
based virtual arrays. When this capability 
is addedi the data acquisition specific 
hardware creates a synerqy with the fund- 
amental system hardwaro such as raad/ 
write memory or floppy disk. 

Another example of a peripheral driver 
package that I developed is a memory- 
mapped video graphics package. The 
typical hardware interfaces ranged from 
240s(256 rBBolution up to 512x490 resolu- 
tion, with as many different methods of 
addressing specific dots on the display. 

Conceptually, we want, first of all, to 
be able to plot physical X,Y points inde- 
pendent of hardware specifics. A word 
such as PLOT, using X and Y integer para- 
meters on the stack top, can give us this 
capability very readily. 

But to really use grsqjhlcs effectively, 
it is nice to be able to specify different 
areas on the video screen to plot different 
data, as well as scaling functions to adopt 
logical coordinates to this specified 
graphics area. The GRAR-I data type 
(built with a defming word) allows these 
different graphics areas and scaling func- 
tions to be associated, and invoked, by a 
common name. Further capabilities were 
added to allow easy creation of vectors, 
grids, tick marks, axes, and boxes. All of 
a sudden, a very proletarian graphics peri- 
pheral is transformed into a powerful 
tool. And because these new functions are 
all built on the PLOT word, they are 
readily tansferred between systems with 
different hardware interfaces. 

A final software driver to considw is 
that of the hardwere floating point unit. 
It is interesting to consider this from both 
a FORTIHt, and a conventional language 
point of view. In a language such as 
PASCAL, the system generally has built in 
software based operators for floating 
point. Because the system is not inherent- 
ly extensibie, the addition of a hardware 
floating point pt'^riphcral requires either a 
manufacturer rowrttf; of the PASCAL 
floating point routines, or else a user 
interfac;e through PASCAL functions or 
procedures. The fornier requires marsu- 
facturer acceptance and support of a new 
hardware peripheral; unless a very popular 
device, suciT support will be reluctant at 
best. The latter requires a very awkward 
language syntax to Ifwolte hardvrara float- 
ing point cE^abilities. Either way, the 



prohiem is that the hardware has to be 
forced to conform to the manufacturer's 

language f-tandard. 

At the Medical Center, a hardware 
floating point package was easily added as 
an Bxtention to the basic FORTH system; 
the language adopted the hardware! 

Aiw^vartism ir Pntent? 

At this juncture it is valid to a^ if 
FORTH justified itself in its use at the 
University of Rochester Medical Center. 
Is it an anachronism of the past, or a phil- 
osophy port ending the future? 

Admittedly, FORTH is somewhat 
limited without such things ms a file 
system or procedural name scoping of 
variables. Perhaps there should also be 
less explicit knowledge of addresses, and 
more system security. Perhaps. But if so, 

then these things will be evolved as 
FORTH matures. 

It is what FORTH espouses, though, 
that justifiss its use. !t allows ^a^dv>'^^e 
components to dictate the software 
design, thus allowing rapid incorporation 
of technoiogicai advances. Other lang- 
uages force conformance of hardware to 
language standard»~a stow, expensive 
process. 

FORTH allows isolation of users from 
hardware dependencies, and adds capabili- 
ties to the basic hardware. The result is « 
user wvironment that n^ersedea specific 
machine configurations with concept 
oriented, yet free syntax, computer opera- 
tion. The FWtTH system developer might 
need to know "how", but the system user 
need only know "what". Conventional 
systems, to the contrary, generally require 
everyone concerned to esk: "vtfhy?" 

FORTH encourages an exploratory 
development technique. A user can 
choose between interactively trying con- 
cepts, swriting full programs, editing pro- 
grams, compiling programs, and/of debug- 
ging programs. He or she can do this in a 
single, consistent FORTH environment, 
utilizing any of these phases of develop- 
ment as required. The result is efficient 
use of all system resources. 

The embodiment of the FORTH philos- 
ophy is that programming is not what it is 
often taught to be: the application of top- 
down program rni rig techniques to a single 
problem. Instead, it involves a series of 
interrelated problerns all related to 
syato-ti uiic. This might nitan s sat of 
words tha? allow a rese.T.'chf>r tii control a 
TV digitizer, or it m?^y mean a series of 
words to calculate and graphically display 
the results cF a mathematical analysis. 
While thp series of capabilities needed will 
always vary between different systeimB) it 
Is only by providing a rich enouqh vocabu- 



lary that a user cm^ have a flexible, effec- 
tive, and friendly system. FORTH is 
unique among languages in that it encour- 
ages the programming of soiutior^ 

Peter Maimers is a senior laboratory Migi- 
neer in the diagnostic ultrasound research 
laboratory within the Department of 
Radiology at the University of Rochester 
Medical Center. 
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Correction to f EDIT 

Sorry you had trouble with FE331T. The 
listing was retyped at PIG and several 
typos creeped in. They ares 

1. SCR 64 Line lOt compile should be 

ookpile: 

2. SCR 6? Line Z3t 1+ /MOO should be 1+ 
16 /MOO 

3. SCR 67 Line 4B: B/BUD should be 
B/BLF 

a. SCR 67 Line a9i : E should be ; .E 

5. SCR 67 Line 50! + ALIN should be 
t-ALIN 

Vou are perfectly right that source 
text should be loadable. 1 talked to some 
of the people at FIG about this and they 
were acutely aware of the problem but 
they are simply not set up to directly 
reproduce listings in FD at the present 
time. They do the l>est job they can vnth 
the resources available to them* and tl»ey 
work dam hard at it. I cant fault them. 

REPL is a pseudonym for the fig- 
FORTH line editor definition, R . I used 
the pseudonym because FEDIT was the 
first prcgrarn I wrote in FORTH and 1 
wasn^t really familiar enough with 
Vocabularies to comfortably use a word 
that was already used in the FORTH 
vocabulary. 

Let me know imw it works for you. If 
you would like e machine produced listing, 
I could nx\ one for you from my current 
verdon. Let me l<now. Good luck. 

Edgar H. Fey 

18 Calendar Court 

La Grange, IL 60525 
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Fig. 1: Block diagrmm of a typical 5-100 baaed niicrocamputer; this one It used to study 
Uood vsin meeiiatrics. 
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Fig, Z; Block digram of LDA analog oleccronica timing control Interface. Kflcro- 
computer sets interface parameters, but timing then runs indepervdently Ltslng 
PRFSYNC and ACK hEV1d^^laking signals from Nova Minicomputer data acquisition 
system. Because the micracomputer can synchronize to timing hardware^ othar oapAUl- 
itios such as attenuator and frequency control can be utilized. 
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Rq, 3: Diagram of vein mechanics experimental chamber. Microcomputer samples 
pressure and force signals, and determines vein diameter from software vwlysls of TV 
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DATA STRUCTURES 

TmjnMMUNtCATlONS FRONT E^D 

John A. Lefor 
University of Rochester 

AA tract 

URTH, the University of Rochester- 
dialect of rORTH, was used to implement 
a telecommunicatians front end for an 
IBM J032. This package provides access to 
the IBM 3032 from as many as 16D AECIl 
terminal at speeds up to 9.6Kb. Each of 
these terminals contend for IZB simulta- 
nsouB connections at the IBM computer. 

The raasons for choosing URTH u the 
developfnent language and a review of the 
major advantages and disadvantages at 
u»ng Urth for this project is discussed. 
Also, some conclusions as to the applica- 
bility of URTH, and the data structures 
used in this application is reviewed. The 
use of conventional data structures for 
providing information pat^s between the 
various components of the system is 
examined and the possible advantage of 
!ess conventional data structures more 
firmly baaed in URTH constructs is ex- 
plored. 

A plan for development of ^miler sye- 
tems Is presented which integrates acme 
of these ccnicerns and pramises a better 
structured system. 

Introduction 

In 1977, the University of Rochester 
Computing Center first got involved with 
the FORTH language. The initial devel- 
opment in FORTH was the implementation 
of various flavors of the TORTH system 
known collectively as URTH. Most of the 
URTH systems developed have provided 
multitasking capability on a variety of 
micro-, mini-, and mainframe computers. 
During the development of the various 
URTH systems, a number of people within 
the Computing Center showed interest tn 
using an URTH based system far develop- 
ment of real projects rather than viewing 
URTH as just another academic curiosity. 

Concurrent with the development of 
the URTH system, was the growth of tele- 
communications in computing at the Uni- 
versity. A need for additional tele- 
communications lines into the computer 
was fast becoming a necessity and the 
financial support for such a purchase was 
on the verge of beconning a reality. 

In thj^ onvi ronrnernt J the design and 
implementation of a locally designed tele- 
communicatione front end w« beginning 
to emerge. The front end had to exist in 
an academic computing center where the 
need fat teleprocessing wss growing. The 
front end liad to communicate with an IBM 
host (it was generally believed that the 



IBM environment was at the University for 
many years to come}. The front end had 
to provide access for the ever grou^ng 
number of ASCII terminels being 
purchased for both computing and non- 
computing environments. Importently, the 
front end had to provide for access to the 
IBM host from more terminals than could 
be dedicated to the hast at any one time. 
The only frofit end which could possibly 
meet these goafs and be reasonatjly cost 
effective had to be one of local design. 
meeti'"Tg io"a! requirements. 
Features Provided 

The front end designed at the Uni- 
versity of Rocliester Computing Center 
does provide some unique feature* to the 
users of our BM 31132 computer. To be 
sure, the features are not unique vnthin 
the context of computing, but are net 
generally available in an BM mainframe 
environment. 

One of the major advantages provided 
by the locally designed front end is the 
ability to switch between systems from 
the same terminal. In a traditional (non- 
SNA) IBM mainframe, it is not always 
convenient to have a terminal switched 
betwe£^n different software teleprocessing 
applications. Typicaliy, a terminal either 
is connected to one application or an- 
other. With the locally designed front 
end, it is possible to dmose the appli- 
cation ot which the terminal is attached. 
In effect, the front end Is a port contender 
for various applications on the mainframe. 

The second major feature arising from 
a local front end is the ability to support 
an XON/KOFF protocol. Since the IBM 
mainframe communicates with its termin- 
als in 3 half duplex mode, XON/XOFF 
support is not traditionally available. The 
local front end is based on full duplex 
communication to the terminal so 
XOisi/XOFF can be supoorted in a fully 
pi'^■■c.■ -'siflhior.. Those terminals which 
have buffers which can overflow can turn 
off the input at will, a feature not avail- 
able without special support in the IBM 
world. 

The front end is today running at the 
University of Rochester Confuting Cen- 
ter. Ii is supporting 160 ASCII terminals 
contending for 12B host computer ports. 

Each terminal can seiect connection speed 
between 110 and 9600 Baud as well as s 
few other tailored features. The fact that 
the implementation continues to run fre- 
guently appears to be a miracle but repre- 
sents some faith that the concept is at 
least esscntislty sound. 

Hardwaire Decision* 

In order to implement the telecom- 
munications front end to an IBM 
computer, the processor chosen for the 
implementation had to provide the capa- 
bility to interface to an IBIvl byte multi- 



plexor channel. Since the protocol for 
d>annel interfacing is non trivial, there 
are a limited number of vendors of mini- 
computers who were able to provide this 
interface capability. Another important 
consideration in the design of a telecom- 
munication; fron* end is the realization 
that if a failure should occur in the front 
end, there is a perception that the host 
computer failed. Because there is great 
need to access the host computer, it is 
undesirable to have hardware failures 
affecting the front end. To this end, the 
mini-computer chosen as the front end had 
to have both a history of reliable service 
and B maintenance team capable of 
repairing any difficulty M^th a minimum of 
fun. 

In evaluating the available mini- 
computers against these criteria, the pro- 
cessor which was finally chosen was a 
Digital Equipment Corporation POP 
11/34. The interface to the channel Is via 
DX-llB, and the ASCII terminals are 
supported by iDZ*il's factually many of 
the lerniinais are supported by a Digital 
Communications Associates Z05, which 
emulates 32 lines of DZ-II on a single 
guad height board)* 

In retrospect, we can see that though 
the PDF 11/34 does work in the required 
environmmt there are aome deficiencies. 
The most notable is in the maintainability 
of the DX-llB (ttie channel inter-^ce 
which connects the PDP 11/54 processor 
to the IBM processor). There are so few 
DX-llB's in production throughout the 
United States that the DEC customer 
engineers are relatively unfamiliar with 
the details of its operation. When subtle 
problems have occurred, the repair of the 
problems has taken considerable time and 
talent. To be sure that the subtle difficul- 
ties were discovered and corrected is a 
tribute to the engineers dedication to the 
problem, but a more popular interface 
would probably have been repaired in a 
shorter time. 

Software DeeMcma 

In determining the nature of the soft* 
ware to run for this application, it was 
necessary to evaluate the probable struc- 
ture of the end goat and to consider all the 
concerns of a project of this sort. After 
the major considerations are evaluated, 
the best software choice can be made 
based on the concerns and knowledge of 
what is available. 

A telecotrimunications front end is a 
realtime device which must he able to 
handle a relatively large number of poten- 
tial i/Q devices. In particular, many ter- 
miT«ls are expected to be connected to 
the front end. Also, there were consid- 
erations for attachment of synchronous 
lines for support of Hasp 8 i sync, Ftemote 
3170% and ItcsI area network communi- 
cations. All these considered together, it 
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was important to choose a software 
implementation which provides support for 
reltime device handling. 

The wide variety of I/O devices which 
were contemipiattd for the front end alao 
reuired that the software provide tools to 
help the designers of the system gain 
underst:andLnq of a wide variety of hard- 
ware aevicps, Tnere were going to be 
a£>'ricfirurtou^ mid synchronous devices as 
well dS a channel interface which had no 
well defined characteristics (the best 
docurnentation of how the 'J\-11B wortted 
was found in tfi^ diagnostic prograrns sup- 
piled for hardware maintenance). In 
addition, there was always the possibility 
of needing to support a new and different 
class of I/O device. Though the manuals 
documented how the hardware worked, 
any softv/are which would allow inter- 
action with the unfamiliar hardware would 
be beneficial In the debugging of the over- 
all system. 

Another area of debugging which was 
considered in the software choice was the 
software protocols. The connectiori to the 
channel of an IBM computer by asyn- 
chronous ASCII devices invokes a non- 
trivial set of software protocols. A simple 
example of the kinds of problems is in the 
transmission of any single ASCII character 
to the channel. In the IBM environment, 
the software running in the processor 
expects that any ASCII characters trans- 
mitted from a telecommunications front 
end are sent not as simple ASCII 
Characters (as generated by the terminal), 
but rather demands that each ASCII char- 
acter be bit reversed. Though this is not 
a difficult feat to accomplish, it points 
out the nature of some of the software 
protocol issues which must be dealt with 
in a talecranmunications front end. 
Suffice it to say the software used to 
design the front end would benefit the 
designer if it helped to identify^ and 
resolve, software protocol issues. 

In the development of any realtime 
software project, it is recognized that the 
throughput of the system is important. 
The telecommunications front end is no 
exception. Since there ore to be a large 
number of 1/0 devices providing input to 
the software application asynchronous to 
the operation of the software, it is imper- 
ative that the application software be able 
to keep pace with the demand. On the 
other hand, the inability of the front end 
to keep pace with the demand is not criti- 
cal. If a character destined to a terminal 
is lost, a human being wil! no; die but a 
programmer may get upset. Keeping 
these priorities in mind the project had to 
be implemented in an environment which 
was not wasteful of processor time, but 
there was no need to be alarmed if ttfere 
was the potential to loose data. 

The hardware declsiwi mada specific 
features of the processor had to ba con- 



sidered in the software choice. Speci- 
fically, the PDP 11/34 had 54K bytes of 
memory. We had to have some degree of 
confidence that the entire system could be 
■Packaged in £4K bytes. If that was not 
possible, the development time could be 
slowed down waiting for shipment of addi- 
tional memory. The speed of the 11/34 
processor led us to believe we would have 
sufficient CPU to do the job, but not a lot 
to spare. 

The final and perhaps major consider- 
ation which affected the choice of 
software was the perceived development 
time. The project was initiated at a time 
when there was an extra IBM processor at 
the University. It would be poaslble to 
design and debug the entire front end on a 
processor which was not in use. That was a 
real opportunity not to be passed up. 
l-lowever, the processor could not remain 
idle for too long a time. Any software 
peckatje which could help to shorten the 
development time and thereby allow de- 
bugging of the front end on the unused 
processor would be of great benefit to the 
implements ti on. 

AltBTTwUve Sof twaire Strategies 

Examining the Issues in making the 
software choice, there appear to be three 
alternative software strategle*. The use of 
assembler language, the use of a high level 
language such as C or Fortren, or the use 
of URTH. 

Assembler language provides a number 
of solutions to the problems outlined. It 
tends to be compact in memory usage, it 
certainty has the potential to make most 
efficient use of the limited CPU, and it is 
quite capable of handling the foreign 
devices needed a front end. However, 
the assembler has a few drawbacks. 
Probably the major difficulty with assem- 
bly language is the extended development 
time. Debugging is slow and tedious and 
design of code and date structures to aid 
debugging is totally a responsibility of the 
progrsnimer. Thus, development of a 
major application in assembly language is 
concerned both with the solution of the 
problem but also much effort is spent on 
good design and coding technigues. 
Another difficulty with the assembler is 
maintainability. Each programmer has an 
individual design style. The documenta- 
tion rests largely in design of the code, if 
the original dengner is no longer available 
for maintenance of the project, there is a 
long learnirNi curve to train a new indi 
vlduaL 

High level languages solve many of the 
difficulties with assembly language. If the 
language is well conceived fot a realtime 
problem, it will support the difficult 
hardware Issues end will provide m frame- 
woH( for data structure design which pro- 
vides readeblltty' and maintainability of 
the software. A ma]or difficulty with high 



level languages is Hieir use of memory, 
and sophisticated operating system ser- 
vices. These two concerns may make a 
lar^r faster CPU needed for effective 
execution of the application. Another 
drawback of both the assembler and high 
level solution is the lack of inherent inter, 
active develoment and debugging tools. 
They typically cen be designed into the 
system, but they generally are not present 
in the besln environment. 

Evaluation of UTiTH 

URTH appears to meet many of Che 
goals in the software choice. Thou^ 
there are limitations, the advantages seam 
to outweigh the disadvantages especially 
when design time Is so important a consid- 
eration. 

When looking at URTH, a clear advan- 
tage afforded by URTH is implementation 
time. Most of ttie other advantages pro- 
virlec: by URTH can be directly tied to the 
speed of implementation. URTH provides 
easy access to any set of unusual devices, 
because the device handlers are ach tai- 
lored to the system and ttie hardware, 
□nee a program is debugged in URTH, 
there is good ressoci to believe it will 
continue to wari<.^ Another major 
advantage offered in the URTH environ- 
ment is the enormoui flexibility in iteslgn 
of both source codes and data structures. 
The ability to code both high level URTH 
and mechine level code and to achieve a 
uniform interface provided many oppor- 
tunities to speed up inefficient code. The 
ability to design new data strucutres to 
work in a large scale environment offers 
much flexibility In design. 

The URTH environment Is not without 
fault. The fact that URTH is an inter- 
preter does mean the code is not as 
efficient in CPU speed as possible. Of 
course, the ease of generating assembly 
code helps alleviate this problem. How- 
ever, a major drawback of the URTH 
environment stems from its flexibility in 
data structure design. 

The very fact that It is possible to 
design any needed data structures coupled 
with the implementation of the trsditionel 
data structures of arrays, constants, and 
variables created some difficulties in the 
design of system which had so much pres- 
sure for development In a Short time. 
There was not a lot of time spent on 
development of the best data structure for 
the problems encountered. Rather, tradi- 
tional data structures were utied to meet 
individual demands. In p,'5rti(:utar, many 
arrays were implemented for storing of 
information relating to specific I/O 
devices, and queues (obtained from a free- 
pool) were used to buffer data between 
devices. The use of such deta structures 
iiad two major impacts on the project. 
First, the queues ware sufficiently diffi- 
cult to handle as to have impact on the 
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^eed of the overall system. The use of 
the arrays to huld information for later 
processing yiulded much difficulty in 
debugging individual wrjrds and tended to 
leave side effects which had impact on 
wofYii alrsady debugged. 

Thus, the use of URTH haa mtny vtr- 
tuaa but It is crucial to recognlza am 
particular iasuea which maiy lead to 
difficulty in debugging. Using data 
structures such as arrays and variablM to 
communicate irvformation between tasks 
in ^e front end tended to leave open 
many portential pitfalls in the debugging 
and design of a system as complex and 
highly integratad at a front end. 

Altefnatlva Darign 5trats0es 

In examining the resulting front end 
for difficiencies, it becomes clear that 
there are some strategies for alterhstive 
design whi^ could limit the difficulties 
encountered in any aimilar realtime 
project, end would mal<e URTH a v^icle 
far well designed, well integrated, and 
effective ayatems deaign. 

The issues of code design are well con- 
sidered in URTH. The ability to switch 
between machine level code and high level 
URTH provides a classic tradeoff between 
speed of execution and memory utili- 
zation. The fact that the interface 
between both environments is standard 
allows all design in high level URTH, and 
conversion to machine code when and 
wfiere appropriate. Ih this «te», URTH 
provides suffflcent tools and a good set of 
options. 

In the data design area, URTH provides 
so many options that the best data struc- 
ture choice is very much at the control of 
the programmer. In the case of the front 
end design, the traditional data structures 
were not sufficient Co effect the job but 
there was insufficient time to design an 
Optimal data structure. In retrospect, it is 
possible to peruse the alternatives and 
choose a structure which provided the 
flexibility needed, and also limits the side 
effects from preventing effective debug- 
ging of words. 

One of the major advantage* URTH 
provides ovwr alternative software 

approaches is the staclc. Proper design of 
URTH words with parameter passing via 
the stack helps to insure U\at a debugged 
word will tend to continue to work, and 
will have no side effects Given this 
observation, it wotjld be natural to use the 
stack to pass parameters in the telecom- 
munications environment. Unfortunately, 
the stack is not useful in communication 
between tasks, and the stack is difficult to 
address and use when too much informa- 
tion is passed. In the front erxJ, there are 
so many unrelated pu'emeters which need 
to be passed between tagks that the stadc 
is not useful. But, tfw concept of a stsdc 



does solve one of the inajor difficulties 
encountered in the front end design. Given 

this set of considerations, it seems like a 
good idea to define a "named object 
stack" for each 1/0 entity defined in the 
telecommunication environment. When a 
particular I/O device needs some form of 
service, the named stack is invoked and all 
data relating to the I/O tlevice is availa- 
ble. The stack can contain pointei« to 
ring buffers as well as current status of 
the device. Using this strategy provides 
an environment that naturally fits within 
the basic strucutrs of URTH progrsm- 
ming, makes effective use of constructs 
within the URTH system, and promotes 
good URTH progiamming practices which 
minimise the side effect problems. Over- 
all speed of the application is not 
significantly impacted and many old 
functions can take advantage of the data 
structure. 

The stack will contain sufficient 
volumes of Information about each I/O 
device that it may be advisable to create 
a "framing" of the stack. This would allow 
access to individual parts of the stack as 
if it were the current top of stack, thus 
allowing access to more data in a conve- 
nient notatioru 

Summary 

The telecommunications front iind 
designed and implemented at the Univer- 
sity of Rochester Computing Center is a 
useful model of many realtime applica- 
tions. In the dedgn ere found a number of 
flaws which are primarily related to the 
particular pressures present at the time of 
the deNgn. The dwice of URTH as tiw 
software vehicle a^Mars to haive tiaan an 
excellent one however, tfie choice of data 
structures to use within the URTH envi- 
ronment was not as well conceived. 

URTH provided a software 
environment which clearly effected time 
effective development of a complex 
system. It provided a comprehensive 
interactive debugging environment with 
the ability to address specific speed 
inefficiences in a uniform manner. The 
major drawbacks to ttte URTH environ- 
ment raaulted from the choice of data 
structuFes fof intertask commiviication 
within the application. 

URTH does provide tools to develop 
the optimal data structures for any par- 
ticular application. In the case of real- 
time applications, tht^ choiCF^ of data 
structures is parti culsrly :;ritic8l. From 
my experience, I believe that a data struc- 
ture similar to the named object stack 
would benefit many realtime aoplications 
in URTH both function provided and in the 
limiting of side effects so prevelant in 
global data etrucutres such as arrays. 

A second feature which would be valu- 
able in an URTH environment would be 



any useful stand-alone dump with Indexing 
to help the programmer wa!i< through the 
dictionary. When total application col- 
lapse occun, URTH is not very informa- 
tive as to the nature of the problem. A 
memory dump (with a good index for the 
dictionary) would help to detiug some 
rather sticky timing problems. 

Overall, URTH is a good choice for 
development of realtime applications, but 
care in the design of data structures 
should help to make the overall mainte- 
nance of the application a simpler chore. 

Footnotes 

1. This is not simple an example of a per- 
verse IBM, but instead is another fad 
of IBM computing history. The stan- 
dard device IBM used to connect ASCII 
terminals to the host (a 270x} was not 
designed using today's UARTS, rather 
It collected the bit serial data in a 
register. The data was collacted in e 
register In such a way as to cause the 
characters to be captured in bit 
reverse order. Rather than correcting 
the problem In the front end, they 
transmitted the bit reversed ASCII to 
the host, and translated the bit 
reversed ASCII to EBCDIC for pro- 
cessing. The software stayed, so the 
need for bit reversed ASCII exists 
today. 

2. This advantage was certainly realized 
in Che actual project. The basic system 
was operational wrfthin four mwiths 
from beginning of the project. 

3. This is dependent upon good URTH 
programming practices. But, in our 
project there became dear a self 
evident truth. We attempted to debug 
so many "words" which were already 
correct, we began to heliev^e that it is 
very difficult to debug a working pro- 
gram. 

4. Converting most of the gueues to indi' 
virtually assigned ring buffers Speeded 
up overall processing by 20% or more. 

5. See Peter Helmers, "Ueersteck", 
FORTH DIMENSIONS, VoL HI, No. 1 
and Peter Helmers, "Alternative 
Parameter Stackil", Proceedings of the 
1981 Rochester FORTH Standards 
Conference. 
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MAPPED MEMORY NWNAGEMENT 
TEO-NIQUES IN FORTH 

Rosamary C. Leary 
Carole A. Winkler 
Laboratory for Laser Eiwrgetlcs 
Unlvsraity of Rochester 

Abstract 

Three techniques for using memory 
managemenl hardware in a FORTH system 
have been irnplemented at the Laborattiry 
for Laser Energetics at the University of 
Rochester. One method uses mapped 
memory for data storage by creating a 
"data window" in the logical address 
space. A second method increases the 
available space for programs by mapping 
tastes in a multi-tasking system. The third 
\1SBS mapped memory for data storage by 
taking advantage of special instructions 
and a second set of memory management 
registers. 

introducUon 

The problem of insufficient memory 
for programs or data is commoniy encoun- 
tered on computers with a 16 bit word 
size. Many manufacturers now offer hard- 
ware to alleviate this problem. At the 
Lkiivaruty of Rochester's Laboratory for 
Laser Energetics we have devised sotii- 
tions to three different aspects of .the 
problem uang FORTH on PDP-11/23 and 
PDP-11 /34 computers. 

Two applications at the Laboratory had 
a need for large image processing arrays 
(up to lOtlK v/ords). We solved this by 
using a double precision array index which 
maps physical memory into a logical mem- 
ory "data window" within the FORTH sys- 
tem. 

On a different, very large FORTH ap- 
plication, we needed both more program 
^aca and more data space. We increased 
the amount of program space by imple- 
menting a mutti -tasking system in which 
certain portions of memory contain the 
rtocleus and common code^ while other 
portions are task specific and are period^ 
Icalty switctied in and out of active use. 

To incrt^^s^^e tht^ Ejvaiiabio data space 
ws are using special instructions and a 
second set of memorv management regis- 
ters on the PDP-li/23 and PDP-ll/3il 
computers. 

Additional material on these systems 
can be found in "FORTH in Laser Fusion," 
by Larry Forsley, in this issue of FORTH 
DIMENSIONS. 



The memory management hardware on 
the PDP-11/23 and PDP-11/34 computers 
consists of two sets of registers that map 
16 bit logical addresses into 19 bit phys. 



ical addresses. One set of registers is 
used when the processor is m "kernel" 
mode, Uw other when it is in "user" 
mode. The mode Is determined by two 
bits of the processor status word. 

Each set of registers contains eight 32- 
bit Active Page Registers (APR's). Each 
APR is actually two registers! the Page 
Address Register (PAI^ which contains a 
base address, and Page Descriptor 
Register (PDR) which contains the page 
length and the access control key. 

The 16-bit iogicfl! address space is 
divided into eight "pages" shown in 
Table i. When the memory management 
unit is enabled, any access to memory will 
be mapped through the APR for that 
address. 

Peae Loaicel fttidress Rande 

(octal) 






- 


17776 


1 


20OO0 - 


3777<i 


2 


40000 - 


57776 


3 


60000 - 


77776 


4 


100000 - 


117776 


5 


120000 - 


13777A 


6 


140000 - 


157776 


7 


160000 - 


177776 



Tebla 1, Loaic«l Address 8^«c«. 

The physical memory address that will 
actually be accessed is a combination of 
the lo^cal address and the PAR for that 
page. Figure 1 shows havt the logical 

address is deriv d. Bits 15-13 of the 
logical address give the page (or APR) 
number. The PAH for that page gives the 
base address in 6U byte blocks. This value 
is added to the block number field of the 
logical addresfj (bits 12-6) to find bits 17-6 
of the physical address. Bits 5-0 of the 
physical address are the same as bits 3-0 
of the logical address. 
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block buffers 
return stack 
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t 

dictionary 
nucleus 



} 



4K 



Figure 2. Logical address space for 
single task without mapped meitiGry. 

Additional information on the PDP-11 
memory manaqemEnt uliit can be found in 
the processor handbool< . 

Data Window and Memory Management 

One way to utilize the memory marH 
agement hardware and additional memory 
is to use it for data storage. Two of our 
applications at LLE require large data 
arrays (up to lOOK words) for image pro- 
cessing. We solved this problem by 
creating a "data window" in our looical 
address space. Figure 3 shows the logical 
address layout of a system with a data 
wi ndow. 



Page 



Block No. 



DIB 



Logical 
Addi'ess 



Page Address Field 



d 

1— ►^^^ 



Physical Block No. 



Active Page 
Register 



DIB 



Physical 
Address 



(Displacement 
In blocks) 

Figure 1. Construction of a Physical Address 

(derived from figure 7-9 of [l] and 
reprinted witli permission from DEC.} 
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~ nucleus " 



24 K 



Logical Address Space With Data tflndoM. 

The block buffers, reti/m atscic, and 
parameter stack are moved down to the 
top of the next 4K word page of logical 
memory, leaving a 4K word gap in the log- 
ical address space. In a 12BK word sys- 
tem, lOOK words of physical memory are 
then accessed through this window. 

The X and Y coordinates of the image 
array are converted to a double precision 
inde>:. This is done by multiplying the Y 
coordinate by the number of pixels per 
line and adding the X ctmrdinate. This 
index is divided by the number of ftsges 
per image. The quotient Indlcatee which 
page the pixel Is in, and the remetnder will 
be the addre^ offset of the pixel into the 
page. 

The reloL-atiorr constant for the needed 
p.-itje ir. si't in rtie PAR so that it can be 
accessed through the data window. The 
logical address of the ptj^el is obtained by 
adding the address offset to the starting 
address of the data window. 

MUltMsridng end M e ^n oty Managetnent 

Our version of FORTH implements 
mulU-taaking in the following manner. 
Each task has a "state vector" which 
contains "hiset" vsriabies that can differ 
from task to task. This includes; 

Dictionary and stack pointers 
Program counter and interpreter 

pointer 

Status flags nnd state indicators 
Terminal I/O routines and buffer 
pointers 

Vocabulary pointers 
Number base 

The state vector ftx' the master task is 
included In the nucleus. 

Each task also has its own terminal 
buffer, dictionary, parameter stack, and 
return stack. New tasks are created with 
« routine called BLDTASK which sUocates 



space for them in the master task's dic- 
tionary. Figure shows the logical 
address apace in an unmapped multi- 
tasking system. 
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Figure 4. Logical address space for 
unmapped system with two tasks, 

return stack 
parameter stack 
t 4 

dictionary 
TTY buffer 
state vector 

Toek state vectors are Unkied to each 
other in a circular fashion, one pointing to 
the next and tiw last bade to the first. A 
"round robin" scheduler starts running a 
ne w taafe when the current task executes a 
PAUSE. PAUSE stores the current 
machine state into the state vector of the 
existing task and sets the new machine 
state according to the new ta^^ state 
vector. 



Additional information 



on mu I ti- 

tasking can be found in works by Forsley^, 
McCourt , and Leary and McClimans , 
Figure 2 shows the logical address space 
of a FORTH application with s single task 
and not u^ng memory management. 

To add program qjace to ow multi- 
tasking system, we reserved s "task win- 
dow" in the logical address space. The 
master task occupies the low five pages of 
address space. Code in this sraa is usable 
by all tae^. 

Mapped tasks occupy pages 5 and 6 of 
the logical address space. Definitiona and 
data within a mapped task are accessible 
only to itself. Each task must have a 
separate vocabulary. If definitiona in a 
mapped task are entered into the FORTH 
vocabulary, the dictionary links will be 
gone when the next task becamea active. 
This uaually results In a aytten) cra^. 
Figure 5 shows the logical address space in 
a mapped multi-tasking system. 
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Figure 5. Logiciii AcJress Space for 
Happed HuUi-tesl(1ng Systen. 

Imptementlng this technique required 
the following changes^ 

Modify the scheduler PAUSE so 
that it sets the page 5 and 6 
mernory iriaoEigement registers, as 
well as swapping in the usual state 
vector information. 
Move the block buffers end master 
task stacks to the top of page 4. 
Change the routine BLOTASK to 
assign the new task's return stack, 
parameter stack, and dictionary to 
pages ? and 6, instead of giving 
them space in the master task's 
dictionary. 

Change BLDTASK to assign physi- 
cal memory to the task. It must 
calculate the appropriate settings 
for APR 5 and APR 6 and save 
them in the task's state vector so 
that they can be loaded into the 
memory management registers by 
PAUSE. 

User Space for Data 

The two approaches discussed pre* 
vlousiy both ran In processor "kernel" 
mode. To increase our memory resident 
data storage In the multi-tasking appli- 
cation described previously, we use the 
"user" mode memory management regis- 
ters. 

The processor status word has two 
mode fleldsi current mode and previous 
mode. The instruction MFPD moves a 
word from the "previous" mode address 
space to the "current" mode processor 
stack (thf? return £l:ac'i< in our FORTH 
implementation). The instruction MTPO 
moves a word from the "current" mode 
processor stack to the "previous" mode 
address ^sce. 

Using these instructions it is possible 
to retrieve and store data quickly and 
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BLOCK * 445 



< MEHORY MftMAGEHENT - US, U! ) 

COIiE Uf ( EflDRS5 CIiATA] R£TfiI£VE FROM liS£K f12tt MEMOKV 

77777i0 B* 300000 * MOVt 



S e)+ FPUt ( FROM ftDFCS OH STACK TO KP V 

7777760 e* * MOVt < PS« BftCK TO NORMAL > 

8 -> RP )♦ HOWf ( RP TO STACK ) 

NEXTr ( RETURN } 

CODE U! { CHATAICADRS]— E3 STORE IN USER MOUE HEHORY ) 



ftp -> 

77777i0 e* 



77777A0 e» 



2 5 1) MOVr < DATA FROH STACK TO RF ) 

300000 * WOVt ( SET PRDCESSOft STATUS UORDl > 

( CUf<RENT = KEKNeLr PREV = US£R > 

S e)+ TPtr < FROM ftp TO AtiRS ON STACK ) 

♦ ttOMr ( FSU PACK TO NORMAL ) 

POP Ji < RETURN WITH CLEAN STACK ) 



«»«»«««*»«««*«««f^«t*«t BLOCK t 446 *««*«*««»«»«*««*s«»»«t« 



< MEMORY MANAGEMENT - K>U > 

EtitiE K>U ( CK AIiRS3CU ADRSltCOUNT] C3 COPIES 

( WORUB FROn KERiJEL SPACE TO USER SPACE ) 



'COUNT' > 



W S )+ MOUt 

PO S )+ MOV I 

RI S )+ rtOVt 

7777760 e* 300000 * MOVi 

t>EGIN> 

RP -) Ri >+ mv, 

RO )+ TPDi 

y soBt 

7777760 fft * HOW» 
NEXT* 



( U=COUNT ) 

( ftO = USER SPACE ^^IiDRESS ) 

( R1=KERNEL SPACE AtiTiRESE ) 

( SET PROCESSOR STATUS UQhfi; 



) 



< CURRENT=KERNELf PREV=USER ) 

( FROM KERNEL SPACE TO RP ) 

( FROH RP TO USER SPACE ) 

( DEC H» BRANCH IF NOT ZERO > 

( PSU BACK TO NDRHAL > 

( RETURN } 



BLOCK • 



3|tSJ|t44 3^ ]fc -lit )( -4 lUl-Jlt It 3(1 Jfc 3|t- it J 



( rtEHGRY HANAGEHENT ■- U>K ) 

COI'c U:>K ( LU fi[iRB3[K ftURS JCCDUNT3 C] COPIES 

C HORDB FROM USER SPACE TO KERNEL SPACE > 
U S )+ «Oyf ( U=COUMT > 

RO S )-t- MOUf 

Rl S )+ HOVt 

7777760 B4 300000 » HOW, 



'COUNT ' 



( RO=KEftHEL SPACE ADDRESS ) 
< R1=USER SPACE ADDRESS ) 
( SET PROCESSOR STATUS UDRDi 



BEBIN) 



Rl > + 
RP ) + 



RO ) + 
ti SOBf 

7777760 84 # 



< CURRENT-KERNEL J PREV-USER ) 

FPB, t FROM USER SPACE TO RP ) 
HOy. ( FROM RP TO KERNEL SPACE ) 
( [lEC U> LOOP IF NOT ZERO ) 
MOVt < CURRENT=KERNELi PREV=KERNEL ) 
NEXTt ( RETURN > 



iS 



efficiently, and the data stored is 
accessible to all karfwl mocto praqtams, 
whether tiiey are mapped tasks or not. 
Datg tables that would otherwise need to 
be disk resident because of their size can 
now be memory rerident to speed r»ipons« 
ti me. 

The source listing of the user mode 
da\s $iQrage code is included at the end of 
this article. 

CflndiMian 

The first technique, the data window, 
has been used for two image processing 
applications. One is used to view infrared 
and ultraviolet laser beams in materials 

damage testing experiments. The system 
does circular averaging and calculates an 
absolute intensity within the 10 minute 

shot cycle. 

The other image processing sppiication 
observes X-ray diffraction paLterns pro- 
duced by a nanosecond X-ray source, A 
technique of radial averaging is also used 
here to enhance the diffraction pattern 
and study changes induced by sample stim- 
ulation. 

The second and third techniques are 
used on the Omega Alignment System, 
which now has 17 tasks Installed and uses 
about 140,000 bytes of memory for pro- 
gram space. The user mode data storage 
method is used by the data base software 
and for the intertask meraage queues. 

Although this paper describes tech- 
niques used with DEC PDP-11 series com- 
puters, the techniques are similar to those 
used with any limited address system with 
logical/physical mapping herdware. Thus, 
they are applicable to minicomputers like 
the Hewlett-Packard 1000 series and the 
much newer 16 bit microcomputers like 
the Motorola 68000 and Zilog 8000. The 
techniques are especially appropriate in a 
FORTH-79 context where the FORTH 
machine is defined as having a 6itK byte 
address space, carved out of an arbitrarily 
large physical address ^>ace. 
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A HIGH LEVEL MTEHRUPT 
HAIOL£R M FORTH 

R. L. Keck and L. P. Forsley 
Laboratory for Laser Energetics 
Unverdty of Rocheater 

Abrtnet 

A system for writing interrupt service 
routines in hig^ level FORTH is des- 
cribed. An exwrtple of the utility of Klgh 
level interrupt service in a dynamic data 
■cquisitioT) situation is provided. 

X-ray data from laser-plasma inter- 
action experiments on the GDL laser 
system at LLE has In the past been 
acquired from photographs of osciiioBcoce 
traces. Because of the large number of 
detectors currently being employed, this 
method has become impractical and we 
have chosen to use 12 channel integrating 
A/0 converters for data acquisition. These 
A/D converters are CAMAC compatible 
modules and because of ttie extensive 
CAMAC vocabulary availabla in the UR 
FQRTH-79 system, as wall mt the 
suitability of FORTH fcr uae In a dynamic 
programming environment, FORTH is used 
for the acquisition software* 

The A/D modules integrate the signal 
at each of their 12 inputs for the duration 
of a gate signal, which is derived from the 
laser oscillator. The oscillator is fired 
once every 10 seconds to t^eep it in stat>!e 
operation, hovi^ever, cur data signal occurs 
only when the fgH system of laser ampli- 
fiers is fired as well, an event which 
occurs when a fire sequence is carried out 
by the laser system controller on rnm- 
mand from the operator. We require a 
means of clearing the A/D modules juat In 
advance of the oscillator pulse at which 
the full ayatam wUI fire. This Is accom- 
plished by feeding a resdy-tO'fire tignal, 
provided by the laser system controller 4 
seconds In advance of fire-time, to a 
CAMAC contact sense input module. Our 
acquisition sequence then is: lool< for a 
ready-to- fire signal from the contact 
sense input module, clear the A/D module, 
wait for data available indication from the 
A/0 module and read the data from the 

A/D module. 

The above sequence could be imple- 
mented directly, using the available 
CAMAC vocabulary, by simply continu- 
ot»ly Interrogating a module until the 
de^red condition occurs and then pro- 
ceeiflng to the next at^ This method 
needlessly ties up the computer executing 
loops and prevents it from handling any 
other task while the sequence is in 
progress. Since both the contact sense 
input module and A/D module will gener- 
ate CAMAC Look At Me's CLAM's) when a 
signal occurs at their inputs and a CAMAC 
LAM can generate an interrupt, we c^ 



use an interrupt driven acquisition system 
which will avoid needless looping. This 

requires the writing of interrupt service 
routines in machine code, which is at best 
cumbersome. It would be nice to be able 
to write high level FORTH interrupt ser- 
vice routines which could be readily 
changed. This can, in fact, be done and 
our method for doing this is discussed 
below. 

bnplementatlon 

Our ayatam consist* of UR FORTH-79 
running on a Digital Equipment Corpora- 
tion LSI-11 microcomputer under DEC's 
RT-11 operating system. While a com- 
plete description of the implementation of 
this system may be found in the imple^ 
mentation guide^, we will briefly cover 
FORTI-rs usage of processor registers for 
reference in the following disCLission. 

Four of the processor's general purpose 
registers are dedicated FORTH registers, 
R6, the system stack pointer, serves as 
FDRTH's return stacif pointer (RP). R5 is 
used as the stack pointer (S). R4 is used 
as the FORTH interpreter pointer (IC); it 
contains the address of the compilation 
address (also referred to as the code field 
address or CFA] of the next word to tw 
executed. Finally, Rl is the atete vector 
painter (SV); more will be said about the 
SV later. 

The procedure for eyecuting a FORTH 
word from code is essentially quite simple 
and is accomplished by the word 
XEQ. MACRO (a listing is included in the 
appendix). It accepts an address, into 
which will later be placed the compilation 
address of the interrupt service word, on 
the stack and generates code which will 
place the compilation address of the 
service word on the stack £MOV gilKftDDf^ 
AS) } , loads Uie IC with the eddrass of the 
compilation addren of the return from 
Interrupt codte [MOV iH-ERE+flasIC ] (note 
that <HFRE+8> contains the compilation 
address of RTl (COMPILE RTI), the return 
from interrupt code word) and then jump 
ti the executable code for EXECUTE to 
begin execution of the interrupt service 
word [JMP ■ EXECUTE]. The net effect 
of this code sequence is to start Execution 
0'' a h;gti level interrupt service word and 
subsequently execute the return from 
interrupt code. 

Before execution of the code gener- 
ated by XEO.MACRO can begin, the con- 
tents of the processor registers must be 
preserved by pushing them onto the sys- 
tem stack. Code to do this Is generated 
by REG.SAVE.MACRO, We must addi- 
tionally ensure that the 5 and SV registers 
point to valid memory areas. In the multi- 
tertting UR FORTH-79 system, this is 
most easily accomplished by having a 
separate interrupt task area. The task 
area contains return and parameter stack 
memory allocations as well as a state 



vector allocation. The SV register points 
to the state vector and the state variables 
contained in the state vector are addres- 
sed relative to the value of the SV 
register. 

It should be noted that it is not 
necessary to have a multi-tasking system 
In order to implement high level internet 
routines. This Is because the values of the 
state variables referenced by the Interrupt 
routine are In general identical to those 
for the master task. On a non multi- 
tasking system we would simply reserve a 
parameter stack area for the interrupt 
routines and set S to point to it. It is 
necessary, however, that FORTH be coded 
reentrantly for this scheme to work. 

The SV.SET. MACRO is used to gener- 
ate code which will set the SV and S 
registers. Note that it also changes the 
return stack location. This would not be 
necessary, except for the fact that the 
FORTH stack checking routines requiro 
that the return stack be located In mem- 
ory immediately above the parameter 
stack. The value of the interrupted task's 
return stack pointer Is stored in a free 
vector location |>2T(SV}}. 

SETUP.INT sets the Interrupt vector, 
In this case specifically for CAMAC (the 
vector for the device in slot N for the 
CAMAC crate is located at 400+N*4). 
The processor is run at priority 7 during 
interrupt service to prevent further 
interrupts from occurring. 

To make It simple to creats interrupt 
service routines, the macros previously 
discussed are combined to produce a 
defining word called 

CREATE.CAMAC. INT.WCtflD . 

This word when executed, accepts a task 
area end CAMAC slot number on the stack 
and creates a word which contains the 

code sequences previously developed 
starting at the second parameter field 
location of the newly created word and 
sets the interrupt vector to point to this 
nnde. The first parameter field location is 
reserved to hold the compilation address 
of the word to be executed wh(:r> an 
interrupt occurs. The DOE5> p^irt of the 
new word will load this reserved location 
with the compilation address of the 
desired interrupt service word. 

An ELxampje 

The listing for blocks 3 and 4 illustrate 
how the Interrupt handler is used In our 
acquisition system. A ta^ area (ITASK) 
is created and initiallred for the Interrupt 
routines to use. It must be delinked from 
the multi-tasking system to make it trans- 
parent to the multi -tasking dispatcher. 
Then two interrupt service routines are 
defined (RDY.WORD and FIRE.WORD) 
each with an associated CAMAC slot (or 
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device). They share the same task wea 
since only one interrupt service routine 
can be active at 3 time. 

In block 4, the high level service 
rojtines ari' defined. RDY.INT is used to 
clear the A/D rricirfuie, enable A/D LAM's 
(XCLR XENLAM) and then clear and dis- 
able further LAM'^ from the contact sense 
input module, on occurrence of a LAM 
from the contact sense module. FIRE[ 
collects the A/D data, disables further 
A/D LAM's (XCDLl.ECT XDISLAM) and 
activates another task which will print the 
results (2TASK DISPATCH) on occurrence 
of a LAM from the A/D mockiie. These 
high level rauUnes are installed as the 
interrupt service routines for the appro- 
priate CAMAC devices with the sequen- 
ces; FU3Y.W0RD and 
FIRE. WORD FIR El. Changing an Interrupt 
service routined with this systmn requires 
only defining a new high level handler 
word and installing it as the handler wiwtt, 
e-g., FIRE.WORD F[RE2[ will make the 
word FIRE2[ the new interrupt service 
routine for the A/D mfxlula. 

Conclualon* 

We have shown that it is possible to 
write high level interrupt service routines 
in FORTH. This makes it possible for pro- 
grammers unfamiliar with interrupt pro- 
gramming to easily write interrupt service 
routines. In addition, the facility with 
which this system permits changes to be 
made to the intemqit handlers makes this 
en ideal wey to handle data acquisition tn 
a rapidly changing experimental environ- 
ment. 
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APPENDIX 
WORD LISTIH08 

BLOCK 1 «****»«**««*»«$«»»«**»«»«*»«»X»»*t««*«*«t«*t«»*<«C»«« 
( Hiah l»vml FORTH Intvrrurt hartdlvr rlk l^f 25-»«w-81 ) 



: REG, RESTORE. MACRO 

ASSEM&LER 5 no 1 RP 
CJDE RTI ( res 

fiP 52T SV I) MOyt REG 
^ XEO. MACRO ( 
ASSEMBLER S -) SUAP 9* 
IC HERE 9 + * 
• EXECUTE P 
COMPILE 

FORTH I 

% reo.save«hm:ro 
assehbler £ bo rp -> 



( <>-<>! restore raaislara 0-5 %\ 

)f MOVt -1 +LO0P FORTH » 

tore re3i5tei>s> return fro» intvrpuFt •> 
RESTORE. M;>iCRO RTI p FORTH 

<3ddr of xeo wordi assemblw tlsie>-<> 

MOVp ( push handler word sddr on stack) 

MOVf ( pr»»at the IC } 

JMPr C Junp to »>s*cui» > 

RTI < pointer to r)«xt Inatruction ) 



< <>-<>» s»v» rMisters 
I MOVf LOOP FORTH i 

— > 



5 «) 



BLOCK 



Z »|ttrX««««t«t»*»««*««*««»«««»«S«t)k**«*««t*«*«»»S««««t«« 



{ more interrupt stuff 25— MV— 81 plk ) 

: SETUP. INT ( ::5lot*><co<i» •ddp>-<> set canac vector «) 

SWAP 4 * 4000 f SUP ROT SWAP ) 

2+ 3400 SWAP ! % 

I SV. SET. MACRO < <Sy loc>-<> set sy for interrupt routirFes *) 

ASSEMBLER SV S«AR # MOVr S 14T SV I) MOV, 52T SV I) RP MOV» 
RP 16T SV I> HOVt FORTH % 

X CREATE. CAMAC. I NT. UORD < <SV loc><alot»>-<>t create int. «) 

( defin. word. *) 
<BUILOS f HERE SETUP. INT HERE 2- REO. SAVE. MACRO 
8UAP SV.SET. MACRO XEO. MACRO 
DOES> CCOHPILE] INSTALL SWAP I f 



BLOCK 3 %%%n%*%%%%%%%%*%%t.*%it%%1i.%%t.%*.%%%%%%%%%n%%%%%%%%%*%%%% 
( Intarrupt task srM initislization rlk 16SEP81> 



20 30 

ITASK 
ITASK 
ITASK 



ITASK 
ITASK 



47 BLDTftSK 1TA8K 
TCLEAR 

OUP > 8V DUP t 

DISPATCH 



( ePMt* • task at>aa *> 

( inltisliza task area *} 

< clalfnk task from task list *> 

( [dark task as aetiv^ *) 



< create a readi< to fire handler word for CAMAC slot A *> 
& CREA TE. CAMAC. INT. UORD RDY.UORD 

( create a fire tlM» word for the A/D Module *) 
XAD CREATE.CAHAC. INT* WORD FIRE. WORD 



BLOCK 



IS 

4 



( xray interrupt service 
40 120 47 ELDTASK 2TASK 

: Rrr.iNT 

XCLR XENLAM 6 N A 2 F DROP 24 F ( 
» FIRE! 

XCOLLECT XDISLAM 2TA8K BtSPATCH t 



l3-3Pr-81 rlk ) 
< task area for post fire word 



< rdti fire int handler *) 



( fire ti»e handler %\ 



RDY.UORD RDY.INT 



< Make RDY.INT the ready to fire «) 
( interrupt service routine t) 



FIRE. WORD FIRE! ( Make FIRE I the fire tiM interrupt handler «) 

— > 



FORTH DIME?MS10h4S Hl/^ 
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OPTIMIZED DATA STRUCTURES 
FOR HARDWARE CONTROL 



Joseph O. Sawicki 
Laboratory for Laser Energetics 
Uoiversity of Roct^ester 

AlMtnet 

Data structures have been developed to more easily control hardware, A disk driver is uaed as an exsrnple for exploring alternative 
rORTH date structures and ways of optimizing them. Time mamplM ihow that FORTH data •tnictures are well wited to minimizing 
programming time and increasing software efficiency. 

MriNhKtion 



While workijig at the Laboratory for Lexer Enar^tic* this eummer ona of my projects was to write a general purpMe backup routine 
for a DEC-l!k«^ RX02 mode floppy disk drive. In doing this certain commonly used FORTH tools became useful. This paper will serve to 
illustrate these tools, and the modifications necessary due to the nature of the project. 

DataStnietms 

The TO concept was developed by Dr. Paul Bartholdi and waa described in FORTIH OIMENSIOM5 VoL I INto. 4 and VoL I No. 5 concept^ 
in variables. This could be implemented in high level as foUow84 



VAHIABLE VTO 
: TO 1 XTO i ; 

: VAL <BUILDS ( <if>-<> , ACCEPTS INITIAL VALUE ) 

I>OES> ( <4^>-0;0-<#>, STORES OR GIVES "VAL" ) 
XTO @ 
IF 1 

XTO ! 
ELSE @ 
THEH : 



It would be used like a variable. Entering VAL < NAME > would define a vari^le with an Initial value of zero. To change the value to a 
aix one would say 6 TO<NAME>f 8aylng<NAME> would now put a six on tlw stad<. 

This technique makes the code more readable by eliminating the use of @ and C with variable* (and ' with constants) to accott and 
modify them. The backi^ driver is no exception to this and in fact offers the opportunity to carry the concept one step furthu. In the 
DEC PDP-11 architecture, I/O is memory mapped bo that, for instance, the Disk Control Status Register is at location 177170O and the 
Data Buffer Register is at location 1771720. One way to communicate with these addresses is to define two constants) 

177170Q CONSTANT CSR 
1771720 CONSTANT D8R 

but tberi the use of g and t becornes necessary, A way around this problem is to define a data structure similar to VAL except that it 
contains an address in its parameter field instead of a value. It would also be useful to fetch the address as well as to send data to and 
from the address. An easy, though by no means optimal, implementation of such a structure is given below, 

; TO ( SETS FLAG so THAT A NUN HILL BE STDFcEO IH A RES,) 

1 no ' i 

1 FROM i SEtS FLA6 SO THAT A HUH HILL BE 60 T TEH TROH A RES) 
-1 XTO I i 

"( TEST BED FOR BE6INING OF f!Xu2 DMUER J'Ji ISJUM&l > 
; REGISTER |8MILBE_,^^ BUILDS A HAT A T(P£ CALLED A REOISTER ) 
DOES> ( GIVES REGISTER ADD) CDHTErlTS OR SEHDG DATh 
TO THE RESISTEl! DEPEH0IH6 OH THE STATUS OF !ia>0 
e XTO S ( GET ADDRESS OF REG AKD J&Q 
DUP -1 - IF SUAP I SHAP <6ET COHTENT) 
THEN '~ 
I ^ IF > < STORE VALUE IN RES ^ 

THEH <ero 

Once thpse two structures are implemented it becomes very easy to talk to the disk drive. For enample, if a VAL had been defined 
called IN-TRACK# which contained the track to be read, sending it to the OBR would simply consist of saying IN-TRACKff TO DBR. 
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P6kTH folivlKNSlbNS m/4 



In thtt RX02 mode there are eiqt\t disk commands. They sre all similar in that they need ta have a drive and density bit set and they 
are sent to the CSR. The first problem is solved by a VAL called DRIVE/DENSITY and the four words shown below: 



! SINSU-BEHSITY < <C0«,,--( COM . .-t SETS THE PENSITY BIT TO ) 

DRIUE/DENSITY 23i BIC TO bKl'.'i/i'EHZn i i 
; HOUPLE-DENSITT ( <COh.>-COK- • SETS THE DENSITY BIT TO 1 ) 

HfiIU£/[i£H5]TY 2'jh SIS TO LR I '.'E ■HF.Ws L T ^ * 
; ODRIVE t <COH. >-vCOM,>T SETS THE fiRiyF BIT TO > 

DRIVE/IiENSITY 16 BIC TO IiFtU'E/ BtNS iT r i 
! ICRIUE ( <COM.:'-<COM,> r SET THE DRIVE SIT TO 1 » 

DRIVE/DENSITY 16 filS TO &RIU£/D£ltSITV i 

After setting the drive Hid denaty as desired, the VAL ORtVE/OENSITY can then b« ORed with the command to produce the desired 
results. There are two apprdachea that can be taken at this point. For example, take the command to format a disk in a single or double 
density; celt it (SET -DEN). A word could be defined, along with seven others like it, as shownt 

I CSET-DEN) no drive: /de:nsity or to CSR ; 

The second approach would be to again use a defining word; 

: OISK-COHHAND sBUILDS { <CDK>-<> TAKES THE COM FOii A DISK OR. ) 

POES> ( SET COH ftHC WIVE PEN INFO 0R> AND SEND > 

e Iiftiue/OEHSITY OR TO EISR i 

110 DISK-COHHAND <SET-!»EH} ( USES TO FOfiHAT CISKS SINS OR D£t4) 

Optimization 

As usual we have a classic FORTH space- time tradeoff. The seccnd approach executes somewhat slower (see figure 1) because the 
constant needs to be fetched, but whereas the first approach takes IB bytes per command or a total of 144 bytes, the second approach 
takes only 10 bytes per command plus 2a bytes for the defining word for a total of IDA bytes. Because of the space savings the philoso- 
phy that very simitar things should be grouped togetlier could override the execution speed losses and the second approach was used. 

AU of this would ttave been fine except that when doing the trade to track badcup e MCtor Interleaving technique must be used to 
keep backup times down to a reasonable level. Since these VAL's and REG's have high level IF statements In them and they are used each 
time a sector is read or written, they regulre an overly large interlea^re step size. The solution to this problem is to use ;CODE instead 
of DOE54 Though this makes the word less transportable it isn't seen as a problem since this is a POP^ll specific disk backup. The VAL 
word now can be defined as follows: 

: VAL <BUILIiS ( ;»:--, > TAKES THE INITIAL VALUE OFF THE STACK J 

iCODE ( OFi <:'- :* >i GETS WALUE OR STORES WALUE ) 

KTO F TSTr ( SEE IF KTO POSITIVE ) 
6T If. 

WfAf!HH U n S >t MOW. ( STORE WftLUE ) 
;iTO P t HOU, C ZERO OUT XTD FLAG t 
£LSE> 

S -) UPARAM H I) HOVt < FETCH VALUE OF VAL > 
THEHt HEH. — > 

where W Is the PDP-11 register containing the CFA (code field address) of the word executing, WPARAM is a constant equal to the 
of^et from the CFA to the PFA, and indicates indexed addressing. Not only is the coded VAL fast«- than the high level veralm, but it 
is also faster than a VAR at fetching and the same speed at storing (see figure Z). It was also necessary to code REG as shown betow: 

; RE6 <BUILDS ( BUILDS A DATA TYPE CALLED A REGISTER ) 

fCODE ( <*->-<>f<>-<«>» GETS APDt VALUE OR STORES VAL ) 
XTO P TSTt ( CHECK IF ITO IS POS MEG OR ZERO ) 
GT IFi 

UF ARAH U ei) S }+ (fOUf ( STORE VALUE IM REG ) 
ELSEi 

LT IF. 

S -> HF-ARAH U SI) MOy, ( GET VALUE ) 
ELSE' 

S -) HPARAM U I) MOV. ( PUT T.O.S. ) 

THEHt 

THEHt 

J!TO P a * HOVt NEXTt _ ^ 

Oh ITv 

To illustrate the use of these concepU the FORMAT word vAM be shown. But first to insure that the program doesnl't try to do 
things before the di* controller is ready, two more words are needed that wait for the done and transfer request bit to be asserted in the 

CSR. 

! TR.MAIT C HALTS FOR THE DATA TRANSFER BIT TO BE SET J 

i DggtfElAf?''? 5g?fsS^gR\"^'E'SoV TO BE ASSERTED > 
BEGIH *00 FROM CSR AliB END i 



The diik oommand at tfwwn bsfora wbb emilmtS (SET-DCN). Aft«r racMMng this eommmd On drit controltn- waita tar a "kojT byte 
(1110, the letter I in ASCII) to be asnt to the DBR, therefore the entire command i« coded aa shown: 

; FORMAT -DISK ( <.;-<>, 3£TS THE DEMSITV OF A DISK > 
(SET-DEN) TFt.UAIT 
11 ID TO DBR ( SENS 'KEY* BYTE ) 
DOHE.UAIT i 

To format the disk in the drive one double (tensity one would enter lORIVE DOUBLE-DENSITY FORMAT-DISK; to format the disk in 
drive zero single density one would enter KJRIVE SINGLE-DENSITY rORMAT-DISK. 

Timing 

To show the Rffents of the different approaches timing testa were run. The first contreats the difference between the two types of 

disk commands. In all tests the action was placed inside s double loop liltes 

: TEST 10 DO 30000 DO LOOP LOOP ; 

This routine took 23 seconds which was then subtracted from the other results to ^va the time to do the operation 300,000 times. This 
wat then divided by 300,000 to give the time per operation. These are the results on a DEC LSI 11/2: 

To Send Disk CoMand 
Colon definition .23 asec. 

Defining woi4 .28 «sec. 

Then a high level VAL waa compared to a coded VAL and a VARj 

fetching (msec) storing (usee) 

high level VAL .237 .39 

e«datt VAL .067 .11 

V«l .083 , 093 



Summary 

This papeir not only showed Che usefulness of certain techniques in FORTH but also Illustrates some general properties of the 
language. The first of these is the eaiSB of implementation of new data structures. Through the use of BUILDS ... DOES or BUILDS ... 
;COOE one can first build the structure to suit the needs of the application and then imbed in the executable code necessary operations 
for the structure. Also a structure can aa^ly be given variable execution as in the case of VAL and REG. Another important benefit of 
FORTH is the ease of optimization of the word by the use of assembly code. Changing the VAL and REG words to (CODE took less than 
a half hour. 
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THE STRING STACK 

Michael McCourt 
Laboratory for Laser Energetics 
University of Rochester 

Richard A. MviM 
Production Automation Project 
University of Rochester 

Abstract 

Applications which require a text data 

type are supported by a group of functions 
which operate with string variables and a 
string stack. The string stacic is analogous 
to the parameter stack, however, the data 
type with wtiich it operates is the atring, 
containing length and character data. 

String Oefirwig WcRtfa 

TwQ defining, words are available far 
the creation of string data entities. The 
first is; 

<>»axlMi> STRING -VAK <N4ME> 

which creates a varying length character 
String with maximum length <maxlen>. 
Inv c^ing^NA ME>places 

<l>csiiining oddressxaaxinua string leDgtb> 

on the parameter stack. The first byte 
at < beg inning address>is the current string 
length; the string text begins at the next 
byte. 

The second string defining word iai 

<iiiiiibeE of eIeiiientE> <inaxlen> C) STRING <IUHE> 

which creates an array of variable length 
strings. Invoking 

<i><NAME> 

places <addres5 of tb« i-th stiiii«> <*wtlen> 

on the parameter stack. Note that 
(nunri>ar of element^ x (maxlerO bytes will 
be allocated to hold the string array. 

String Stack Maidpulatlon 

A string stacic, separate from the para- 
meter stacl<, is maintained in memory for 
the purpose of manipulating string data. 
Several words which manipulate the string 
stacV: arc defined in the string stack 
library which can be compiled by estecut- 
ing >STR!NGS (which loads in the string 
stacl< package). Currently ZOO (decimal) 
bytes are allocated for the string stack. 

Tht; quote word (") is available for 
placing a string on the string stack. To 
Stack a string, type: 

" <t«xt>" 

" is followed by exactly one space, then 

<texD delimited by a quotation mark. 

A string print word -SS is used to print 
the top element of the string stack. 



tttttttttttftmt* BLOCK 



9A 



( STftlHG STACK— FIXEP LENGTH STftlHG CCtifflRISGH L1f< lf-SEP-7? J 
: SS i '. note: PARAM OfiHEft NOU <AW>\L£H> 11-JUN-60 » 

i [flDE A- ADU f. LENlf- — [ADDfir fiCDBt = OR f- OR - 1 ) 
( COMfARES CHARS. IN STRINGS A 8 Ei PftRIUISEf RETUttHS IF 

I STRINGS flft£ =1 + IF A>Et> - IF A-,Ei ) 

J STFDO SWAP BO EiFtOP QVEf; i.% Ci^Efi 13 - ROT 1 + 
SOT 1+ ROT DUP 0= MOT IF LEAVE TKIH LOOP f 
( [ADD ttf ADD B) LEKl— 1= OR -I' OR -It SAH£ AS S?FDtl > 
{ EXCEPT ADDRESSES NOT I^ETURNED > «■ t a.r™ , 



SfF S'FPO ROT ROT SDROf- 

( £A0D Ai LEN]---C== OR + OR 

( A STRIN3 DF BLAWKE ""' ' 
8?B SNAP DO DROP [lUP EIL - SUAP If SUAP'OiiP OO 
IF LEAVE THEN LOOP SMhF DROP i — > 



. - ]> COflPARES STRING A TO ) 
RETURNS IF THO ARE EQUAL > 



tt*ttl*»lt***t*«t« BLOCK 
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ttrnftf*********** 



( STRING COMPAfilSON-— VARYING LENGTHS ) 

( [ADD Ai ACIi b, LEN [iIFF3-— OR + OH -1 FIRST TESTS > 
< TO SEE IF LENGTH f:tc. jjUK, ft i B IS ; IF HOI, TESTS ) 
( THE LONGER STRING '0 SEt IF THE EXTRA CHARS, ARE BLANKS ) 
( IN BOTH CASES IS RETLIRrJED. QTKERUISE + OR - > 
: S'BLTEST HUP 0= IF PROF IDROf ELSE Ii'Jf O--. 

IF MINJS ROT DROP S'B MINyS ELSi; SWAP IiORP S?6 THEN THEN i 
( lADH At ADD B] — -CO IF A=Bi - IF A<6, + IF A>E I TESTS ) 
( WHETHER 2 VARIABLE LENGTH STRISHS HAVE BOTH THE SAHE t > 
( OF CHARS. AND THE SAHE imnitl i TYPE ) 
: S? OVER C8 OVER Ce 2DUP - >R KIN ROT It <!0T It ROT S?FDO 
DUP 0<> IF ROT ROT 2DR0P R> DROP 

ELSE WOP R> S7BLTEST THEN ! 



f«tftt>*t*«ttttm BLOCK 
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LAR lf-SEf-79 ) 



( STRI^Jlj STACK WORDS 

SUAR 5S0 SVAR SSM SVAft SST 

1 SSTOP SST 8 » : SSTOPI SST ! t 
! SSORG SSO e t i SSHAX 3SH t > 

( CFROM. TO. LEH 3— CI CHECKS FOR STACK BOUNDARIES ) 
: SOVCHECK OVER SS0R6 Ll< 

IF SSrtAX SETOF ! HT TABDRT THEN i 
( ilPiDli]---: J INSURES THAT ADDRESS POINTS TO STSIHG ) 

: ssyER DUP [lUP CP + ssmax u>= 

IF SSMAX SSTOP < 13T TABORT THEH ; 

( AD[( OF TOP STRINfi]---rA[i OF NEXT STRING DOWN] ) 
; SSDOUN DUP C!> 1+ + i 

( IA[iD]---t3 PUSHES STRING AT AIHiR . TO TDK > 
I SSFUSH DUP Ce 1+ SSTQP OVER - DUP SSTOP! SUAP RNOVE ; 



tttttttttt-tiittttt BLOCK 
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— > 

ttt*ttt.tittit*t*t** 



( STRING STACK UORDS LAR 19-SEP-7? ) 

'DROP I tl [1 REHOUES TOP STRING FRDN STACK *) 

SSTOP SSVER SSDOUN SSTOP > i 

■LEN ( RETURN LEN OF TDS STRING *> 

SSTOP ssvER ce i 

'LOC ( ll--~L2 RETURN ADDR OF TOS STRING ») 

SSTOR 1+ ) 

TjUP ( r3— ri COPT TOS STRING ti 

SSTiJP SSVER SSPUSH i 

SST OF- [^JF SSDOUN DUP -Msm5''yoiWsiiop, 

SUAP SSPUSH SSPUSH i 

'ROT '( []---E] ROTftTE TOP THREE STRINGS ABC->BCA t) 

SSTOP DUP SSDDWN LUP SSDGUN IIUF SSPUSH SSDOUN SSTQP SUAP 
SSTOP! SUAP SSPUSH SUAP SSPUSH SSPUSH i 

-~> 



tttttttlstft****!:** BLOCK 

( STRING STACK yORDS 



100 tttttt*t*tt*»littt*$ 

HAH 13-JUN-8y ; 



'OUER ( Ll—~t-J PUSH :ND STRING DOHN ONTO TOS t) 

SSTOP SSDiJUN SSUER SSPUSH ; 

■2DUP ( []---[} COPY TOP 2 STRINSS t) 

■OVER "OVER i 

•2PR0P ( — DROP TOP 2 STRINGS *) 

■BROP 'DROP ; 

•20VER ( []---[] PUSH JRB AND 4TH TO TOS ti 

SSTDP SSDOUN SSDOUN DUP SSDOUN SSVER SSPUSH SSPUSH J 
■26IIAP { E3— [] EXCHANGE iST i 2ND WITH 3R[J AMD 4TH t) 

DUP SSDOUH SSDOUN SSDOUN SSTOP! SSPUSH SSPUSH SSPUSH SSPUSH t 
•f ( <ADDR><LEN>"-ti PUSH STRING AT ADDR TO SS t) 

DROP SSPUSH i 

--> 
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removing the top element in the process. 

For example^ 

OK " STACK IBIS STRIN6 " <CR> 

OK 

.SS <CR> 

STACK THIS STRING OK 

Notice Oxmt the functiona .SS and . are 
•imilar. Ssveral other functionB operate 
on the •tring ataek in • manner analogous 
to words which operate on the parameter 
stack. The«e are: 



tttttttttttttlfllt BLOCK 
( STRING STACK VOROS COHT'D 



101 tt$*i*t*ttt.tu%tt%* 
HAH 13-JUH-8d } 



■< ( tADR3CLENl STORE TOS AT ADDft. 1 DROP TOS t) 

SSTOP 'DROP S«flP OVER CB HIN 2BUP SilAf C! 1 + 

ftOT SyAF RHQUE i 
( tSTRING]---C3 STORES STfSING IN PAD THEN MOVES H FRDN ) 
( THERE TEj THE TSSS — WORKS OURIttQ EXECUTION TIME ) 

X' 420 WORD • 

r; nuf nuf ce huf : hod 

IF 1+ ELSE 2* THEN + >R ! 

( ISTRING: — -U STOREi STRIMG AT TOP OF DICT. STACK J 

( DURING COMflLATJON ) 
C COMPILE »■ 42D ttORIi 06 DUP 2 MOD 

IF It ELSE 2+ THEN ALLOT ) 
■ STATE » IF C ELSE X* THEN t IHP ' 

— > 



VORO 



FUKCTION 



BEFORE 



AFTER 



"DUP 
"SWAP 

"DROP 

"OVER 

"HOT 

"2DUP 

"ZDROP 

"2SWAP 

"20VER 



copies Lop of KtAck 


B A 




BAA 




xaverses top two 










strings on the stack 


B A 




A B 




removes top of stack 


E A 




B 




copes lad string onto top 


B A 




BAB 




■oves 3rd string to top 


C B 


A 


B A C 




copies top 2 strings 


B A 




BAB 


A 


removes top 2 strings 


C B 


A 


C 




reverses 1^2 with 3 & 4 


D C 


B A 


BAD 


C 


copies 3 & i to top 


D C 


B A 


D C B 


A 


string addition (catenation) 


B A 




BA 





Juit aa the parametar stack relational 
operatora "emokre their argument* from 
the parameter stack, the foUawIng strir^ 
stack relational operators remove their 
arguments from the string stack. The 
logical result of the string relation Is 
placed on the paranneter stack. The avail- 
able relationats are) 



ft«St»t»t««*«ttttt BLOCK 
t STRIHQ STACK HORDS CONT'D 
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HAH ie-hAR~81 > 

t .SS { E3 [] TYPE OUT STRIHQ AT TOSS t) 

SSTOP SSVER 'DROP COUHT TYPE t 
: ■• { <>-<>» PUT STRING IN DICTIOiMRYi HAKE EVEN LEH6TH > 
420 HORD COUNT DUP HERE SUAP It -2 AND ALLOT SOAP CHDVE t 

( SOHE FIXES LENGTH STRING DEFINITIOHS > 

< [ADIiRiMfiX LEM1---C] PUSH STRIHS AT flIiIiR TO TOSS > 
; 'PF im SSTDP OVER - J- SSTOP! SSTOP C SSTOP 
1+ SUAP CMOWE i 
{ [AUtiRiMAX LEN3 — -[] CGFY CHARS ONLY FROfi TOSS TO AIiHR ) 
! 'IF 2DUP BLANK *LE« HIN SSTOP It ROT ROT CMOVE 'UKOP i 



--> 



String Variable Storage and Retrieval 

The string store wortl^ *{( places the 
top of the string stack in the string vari- 
able described by the parameter stack, 
popping the string stack. The string 
retrieve word, "g|, places the string 
referred to by the parameter stack onto 
the string stack. 



OK 30 STRINe-VAR HrSTRINQ <CR> 

OK 

" string text " MYSTRING "! <CR>' 



tt**1fttttntt*t*ttt BLOCK 
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tit*%tttttttititttt 



( STRING STACK WOUHS CONT'D IM 19-SEP-79 ) 

! ■+ < [] — -[3 ADD TOP 2 STRINGS ON STACK LEFT TO RIGHT *) 
'StfAP SSTOP EEDOyW SSVEft C» ESTOf CP PUF ROT + 
SSTOP C! SSTOP DUP 1+ ROT 1+ fttfOUE SSTOP 1+ SSTOpi f 
( [LENf BEGINNING CHAR — [1 REPLACE TOSS WITH ) 
( SUBSTRING OF LENGTH CLEN], STARTOMG UITH SPECIFIED > 
( CHAR OF ORIGINAL STRING ) 
t 'SUBSTR 1- SSTOP SSUER 'DROP + DUP ROT ROT C! SSPLSN i 

( EADD OF 2ND STRtli 1ST CHAR OF 15T STk, LEN OF 2ND, ] ) 

( COFFSET OR ] SEARCHES 2ND STR, FOR ISI CHAR OF > 

( 1ST STR.f IF FOUND. COMPARES 2ND SIR. FROH THAT POINT ) 
t TO 1ST STR > 
■INDEXDO DO OVER I t CP DUER = 



IF Si!EO^+.SST0P It 'LEU 3TF 0- 

IF DROP I It ROT ROT LEAVE THEN THEN 



LOOP 



OK 

MYSTRINQ "9 MYSTRIKB *^ "-t- .SS <CR> String text string text 
OK 



FORTH DIK/IENSIONS Il[y4 



Invoking the nams of ttie string variable 
MYSTRffvlG In the preceding example 
placed <a<kh^3£> <inaxler> on the para- 
meter stack. String stare end string 
retrieve ciieck the maximum and current 
Jength of the string variable when moving 
string dat-g. 

When it is required to move fields of 
fixed length wi^icJi do not contain an 
embedded current Ipno'h in the first byte, 
fis<ed length string store and retrieved 
words may be used. The syntax: is: 

<addxess> <Un«tli> "IP 
<address> <length> "@F 

String Functians 

"LEN returns on the paraitieter stack, 
the length of the string on top of the 
string stack. The string remains on the 
string stack. The address of the first byte 
of the string (one byte after the length 
field) is found by executing "LOC. 
<length> <bBginning character auafcer>- 
"StlBSTR 

replaces the top of the string stack with a 
substring of length <length>, beginning 
with the specified ^eracter of the 
original string. For example, 

OK 



t«**tt*ttttt«tttt» BLOCK 
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" abcde" 2 3 "substr 
cd OK 



.SS 



The "IMDEX function searches for the 
first occurrence of the string in the 
second string. If an occurrence is found, 
its offset is returned an the pBrameter 
ftack. If an occurrsrtce is not found, -1 is 
returned. The top of the string stack Is 
popped. 

String Staek Errors 

Two errors are reported by the string 
stack package: string stack underflow and 
overflow. As stated previously 200 bytes 
are initially allocated for the string 

stack. If repeated overflows are gener- 
ated inoru space can be allocated for the 
string staek by changing the parameter 
passed to "INIT in the string stack 
library. String stack initialiiation is the 
last function performed when the String 
stack library is loaded. 

Summary 

This was the first major software 
package transported throughout the 
University URTH community. Originally, 
it had a few code routines which were 
machine specific to reduce execution 
time. However, these were removed on 
all the systems but the Intel 8080. The 
package has run, v.'ithout change (except 
for ttw above mentioned machine-specific 
code) on Hewlett Packard 2100, DEC 
PDP-11, IBM 360 and the INTEL 8080- 
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( STRING STACK WORPB CQNT'Ti LflR l?-EEf-77 

( [3---L-1 Of; OFFSETJ SEARCHES FOli 1ST OCCURENCE Uf i 
( TOP STR. IN 2NI1 STR,"--IF FOUND OFFSET IS RETURNEH ) 
( OH PARAH STACK ELSE -1 IS RETtiKHED. TOSS IS POPPEIi 

i 'IWEX -1 SSTOP DUP Ci DO 

IF DUP SSSOUH 8SVER DUP Ct KOr 1+ Ct ROT i-f SUAP 
ROT 'INBEXDO 

ELSE ROT ROT THEN 2DR0P *BRDF' i 

( t] — [3 COMPARE % CROP TOP 2 STRlNGSi LEAWE 0><0 OR >0 ) 
! ■? SSTOP BUP SSDOUN S? 'DftOP 'DROP t 

t £1 — IT/Fl LOGICAL =» TESTS TOP 2 STRIHBS i 
! 'T 0- f 

< [3 CT/Fl LOGICAL LESS THAN TESTS TOP 2 ETRIHGS ) 

! •< ■? > » 



itttt»tt*tttt«tt)[)t BLOCK 
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( STRING STACK WORHS CONT'D MAM IS-MAR-Bi i 

J ■> I t3— CT/FJ TESTS TOP 2 STRIH6S FOR > »> 

'T 0< ( 

•<« ( 12 tT/F] TESTS TOP 2 STRINOS FOR <= *) 

•> KOT I 

■>= ( IJ CT/F3 TESTS TOP 2 STRIWS FOR >« *) 

*< NOT ! 

■SPACES ( ■:n>-<>> push a strihg of h spaces an ss t) 

DUP DO SSTOP 1- BL SOVCHECK OVER C! 8STQP! LOOP 
SSTOP 1- DUP ROT SWAP C! SSTOP! } 

: -INIT ( <4CHAflS TO ALLOCATE FOR SS^-;, r INIT SS INTO BICT ) 
1 ?* HERE SSO > ALLOT HERE 2~ DUP SSIt ! SST ■ f 

200T MHIT ( ALLOCATE 200 CHARS FOR STR IMC STACK > 
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t STMMG IJARIAELE flNti STRING ARRAY MAM 13-JUM-SO ) 

( EMAX LEND---n ALLOTS SPACE IN DICT FOR MAX LEN ANl ) 
( MAX t OF CHARS, ) 
: STRING-SPACE BUP i i 2/ HF't! ) 

( [MAX LEND STRING CNAME - BUILDS A STRING VftftlASLE ) 

[ WHEN sNftHE/ IS EXECUTED THE STTE flODR. OF THE STRING I 
( START AML LENGTH ARE LEFT ON THE STACK ) 
! STRIMB-yftfi <BUILDS STRING-SPACE 

(CODE S -) U MDVi ( PUSH PARAM ADDR ) 

S) 4 » ADD> i POINT TO COUNT AMD FIRST CHAR ) 

S -) 2 U II HDUi < PUSH MAX LENGTH ) 
NEXT, 



ntmttt««tst(>*t BLOCK 107 tttt»$****tmttt*.* 

{ STRING ARRAT ROUTINE MAM 13-JUN-80 ) 

) OSTRINE I [♦ OF ELEMENTS- MAX LEN} <NAME; „,*i„,.,„„ ^ 
<BIIILDS SUAP DUP , t BUILD HEADER, STORE t OF STRINGS ) 

D DO DUP STRIHG-SPACE ( ALLOT DIC SPACE, STORE HAX LEN ] 
LOOP DROP 

DOES> 2t DUP 9 ROT ROT 3 PICK ( ADDR OF 1ST ELEMENT ) 

DUP 2 HOD IF 3 + ELSE 4 + THEN ( 1+ TO MAX LEN IF GDD i 

( 2* IF EVEN, 2+ FOR MAXLEH ) 
ROT « 2+ + SyAP I ( STRING ADDR t ELEHEHT OFFSET ) 
< RETURNS COUNT AHlF ADDR > 



( STRING EXECUTION ROUTIHE 



lOB ttt*t^t%t*ttt*tnr%t* 

LPFiMAM 18-«Aft-81 ) 



! -EXEC ( <UORD »«»i£ 0*1 T03S>-<>» EXECUTE HORD IF FOUND i 
HERE 'LEN •« 

FIND ?DUP IF^|XECUTE^^^ ^^^^ ^ ^ UNDEFINED HOfiB ERROR ) 
: -FOftGET ( <II0RD NAME OH TlJSS>-<>. FORGET WORD IF FOtlND > 



HERE * LEI'I * ^ 
FIND ?DUP IF WPARAM f tFDRGET 
ELSE TABORT THEN i 



i UNDEFINED HQRB ERROR ) 
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The first application was for a screen- 
orimted data sntry system. Later appli* 
catiorra included an ISAM data base, a 
menu^drivsn Interface for flaw cytorrwtry 
and a word processing syBtem. The pack- 
age consists almost entirely of Its original 
code written In 1977 by Mike WiUIami^ at 
the Uni verity Computing Canter. The 
major change has been the addition of 
comments. 

Acknowledgements 

We would like to thank the following 
people for their assistance: Mike 
Williams, of the University Computing 
Center, who developed the original String 
Stack Package for URTH on the IBM 360 
and the Intel 8080} end two undergradu- 
ates who worked for Lawrence Forsley, 
Lynn Raymond and Dan Blumenthal) for 
documenting this package. 

This work was partially supported by 
the following sporisors: Exxon Research 
and Engineering Company, General Elec- 
tric Company, New York State Energy 
Research and Development Authority, 
Northeast Utilities, The Standard Oil 
Company (Ohio), the University of 
Rtjchester, Empire State Electric Energy 
Research Corporation, and the U.S. 
Department of Energy inertial fusion 
program under contract nun^er D£-ACQB> 
8aOP40124. 

R. Marisa is the manager of the computing 
facility of the Production Automation 
Project in the College of Engineering at 
the Unlverdty of Rochester. M. McCourt 
was a senior laboratory engineer with the 
Laboratory for Laser Energetics at the 
University of Rochester and is now an 
applications , erqineer for Harvey 
Electronics. 



HELP WANTED 
Associate Systems Manager, 

Primary responsibility for designing, 
debugging and implementing major soft- 
ware projects on the Pulmonary Computer 
System. Programming e)cperlence with 
PDP-11 Assembly language and FORTH 
desirable. StMTie hardware experience will 
be useful. 

Salary range to $35,000. Superior 
benefits package, three weeks vacation 
first year. 

Contacti 

John Gilbert, Employment Officer 

Cedars-Sinai Medical Center 

8725 Alden Drive 

P.O. Box 4S75D 

l-os Angeles, CA 90048 

(213) 855-5529 



NEW PRODUCTS 



FORTH AppUcetien Medutec 
Diskette 

The diskette of FORTH application 
moduels, a new product by TimSn 
Engineering, is a variety package of 
FORTH source code. It contains hundrsjda 
of FORTH definitions not previously pub- 
lished. Included on ths diskette are data 
structures, software development aids, 
string manipulatore, an expanded 32-bit 
vocabulary, a screen calculator, a typing 
practice program, and a menu genera- 
tion/selection program. In addition, the 
diskette provides examples of recursion, 
<BUILOS...DOE5> usage, output number 
formatting, assembler definttorw, and 
conversational programs. One hundred 
screens of software and one hundred 
screens of instructional documentation are 
supplied on the diskette. Every screen is 
in exemplary FORTH programming style. 



Released on two S.2S" diskettes with 
source in ZSO assembler #20080>Z5 ($80). 

Released on one 8" diskette with 
source in 2B0 assembler ^fgOOBO-ZB ($B0). 

Manual for CP/M (or CROMEMCO) 
fig-FORTH above #20080-99 ($20). 



METAFORTH Cross-compiler for 
CP/M OF CROMEMCO COOS to produce 
fig-FORTH on a target macrfitne. The 
tar;^ can Include an application without 
dictionary heeds and link words. It is 
available on single density diskettes with 
12fl byte 26 sector/track format. Target 
compiles may be readily produced for any 
of the following machines. 

CROMEMCO— aU models 
TRS6D Model n wider CP/M 
Northstar Horizon 
Prolog ZBO 



The FORTH screens, written by Scott 
Pickett, may be used with Tirnin FORTH 
or other fig-FORTH. The price for the 
diskette of FORTH application modules is 
$75 (if other than fl" standard disk, add 
$15). To order the forth modules, write 
Tlmln Engineeriny Company, 9575 
Genesee Ave., Suite E-2, San Diego, CA 
92121, or call (7X4)455-9008. 



INNER ACCESS FORTH 
SOFTWARE AND DOCUMENTATION 

Fig-FORTH compiler/interpreter for 
PDP-11 for RT-11, RSXllM or stand- 
alone with source code in native as- 
sembler. Included in this package are an 
assembler and editor written in FORTH 
and Installation documentation. 

This is available on a one 6" single 
density diskette only. #20011-01 ($80) 

Reference Manual for PDP-11 fig- 
FORTH above. #20011-99 ($20) 



Fig-FORTH compiler/interpreter for 
CP/M or CROMEMCO CDOS system 
comes complete with source code written 
in native assembler. Included in this 
package are an a»embler and editor 
written jn FORTH and installation 
documentation. 

All diskettes are ^ngle density, witi- 
5. 25" diskettes in 12B byte, 18 
sector/track format and 8" dlsteettes In 
128 byte, 26 sector/ track (IBM) format. 

Released on two 5.25" diskettes with 
source in 8080 assembler #20080-85 ($80). 

Released on one B" diskette with 
source in 8DBD assembler jIP20QBO-88 ($80). 



Released on two 5,25" diskettes 
#20100-85 ($1,000), 

Released on one 8" diskette #20100-88 
($1,000). 

Complete Zilog (AMD) Z8002 
develoment system that can be run under 
CP/M or CROMEMCO CDOS. System 
includes a METAFORTH Cross-Compiler 
which produces a Z8002 fig-FORTH 
compiler/interpreter for the Zilog Z8000 
Development Module. Package includes a 
28002 assembler, a Tektronix download 
program and a number of utilities. 

Released on two 5.25" diskettes 
#29102-85 ($4,000), 

Released on one 8" diskette 1^29102-88 



zilog ZS002 Develoment Mbdule fig- 
FORTH ROM sot. Contains fig^J^ORTH 
with Z800Z assembler and editor in 4 
(2716) PROMS. #38002-00 ($850). 



For orders and further Information, 

contact: 

INNER ACCESS CORPCfflATION 
Software Division 

Box ess 

Belmont, CA 94002 
(415) 591-8295 



ANNOUNCEMENTS 

Sym-FORTH Newsletter now available, 
contact: Saturn Software Ltd., PO Box 
397, New Westminister, Briti^ Columbia, 
V3L 4Y7, CANADA. 



COK*i.EX ANALYSIS IN FORTH 

Aifred Clark, Jr. 
Department of 
Mschanical Engineering 
Unlvsraity gf Rocheiter 

During my /ears as an ^>gineering 
educator and a reMarcher in theoretical 
fluid mechanici, 1 haw often wished for 
the perfect calculator— a compact 

machine which would perform intricate 
and useful mathematical tasks in response 
to a few keystrokes. The pocket scientific 
caicuiators, amazing as they are, never 
seemed to have quite the power and flexi- 
bility (and certainly not the graphics 
ability) that I hoped for. I always sup* 
posted that my hopes were unreasonabte 
until I discovered FORTH two years ago. 
Having been a FORTRAN programmer for 
20 years, I found the transition to FORTH 
somewhat difficult and even painful at 
times. Originatly, I took up FCM^TH out of 
curiosity, but gradually I realized that the 
quest for the p«^ect calculator was over- 
-it is FORTH plus a microcomputer. 

Perhaps I should say a little more 
about what a perfect calculator is sup- 
posed to do. Among other features, it 
should have (1) standard trigonometric and 
exponential functions, (2) other common 
special functions (e.g., Bessel functions), 
(3) graphics and automated plotting of 
functions, (4) numerical integration, a 
root- finder, (6) special purpose applica- 
tions, such as a direction field plotter for 
first order differential equations, and (7) 
complex arlthmetici including complex 
transcendental functions. Further, all 
procedures should be axecutable with a 
few Iteystrokes. 

The last item in the Uat— complex— is 
in some ways the most stringent test of 
any would-be perfect oaiculator. It's 
certainly not available on any pocket 
calculator. Although it can be imple- 
mented in BASIC, it Is cumbersome and 
requires a large package of si^routines. 
The versions of FOi^TRAt^ available for 
small machines generally omit the com- 
plex arithmetic and complex functions 
which are available on large mactiines. 
With FORTH, however, the extension to 
complex from real floating point is simple 
to implement, easy to use, and powerful. 
Since complex arithmetic is not yet very 
common In FORTH on small machines, I 
thou^t it would be worthwhile to sket^ 
briefly my implementation. 

The most fundamental question in 
Introducing complex analysis is how to 
represent complex numbers. Here it turns 
out that the pure maLhematiclan's defini- 
tion of a complex number as an ordered 
pair of real numbers is exactly what we 
need. Thus the complex number 3.5 + 7.2i 
is regarded as an ordered pair, and is 
pushed on the stack by typing 3.3 7.2 . 
With this convention established, it te easy 



to define all of the important stack mani- 
pulations such as ?DROP, ZDUP, ZOVER, 
ZROT, and ZSWAP, which perform exactly 
like their integer and floating point 
counterparts. The basic load and store 
operators, Z@ and Z[, can be defined in 
terms of ^ and C 

There are many single number opera- 
tions which are useful. Theee include the 
real part REZ, the imaginary part !MZ, 

the complex conjugate CON J, the modulus 
!Z/f the square of the modulus /2/2, the 
reciprocal 1/Z, and the phase ARGZ 
(radians). Most of these are quite simple 
to define. IMZ, 'or eKample, is just 
: IMZ FSWAP FDROP ; where FSWAP ant.! 
FDROP are floating point stack oper- 
ations. As another example, oansider 1/2 
defined by . mjp /2jz tear Kwat r/ 

EROT PHOT F/ OMJ ; 

For ARGZ it is very important to establish 
a precise range and to implement it care- 
fully. The conventional range, which I 
have used, is -PI < ARGZ <= PL Any care- 
lessness in the definition of ARGZ will 
tend to disasters later when mult i- valued 
functions are introduced. Many engineer- 
ing applications require the phase in 
degrees, and it is convenient to build in a 
function OARGZ which supplies this. 



define. For example, Z-i- is defined by 

1 Z* SSOI F4- ER3T fRJT t* FSHU> t 

where FROT is s floating; point ROT, and 
is a floating point add. 

Higher Actions can be defined^ pro- 
vided the underlying real floating point 
has the standard real functions SIN, COS, 
ATN, and CXP. The complex exponential, 
for axample, is titen defined by 

) aocp fsuftp EXP Toup FKyr rout* cos wot t* 

nor F* ncT fbot sm p* 

Other useful functions such as ZSIN, 
ZC OS, 7 TAN, Z=;IN!H, ZCOSI-I, and ZTANH 
are defined similarly. 

Of the multi-valued functions, the 
most useful are the square root .^SQR^ the 
logarithm ZLOG, and the power Z**. As 
an example of the definitions, consider the 
principal value of the square root: 

, 25CR KZAR 2. F/ FStAP SSR FSUHP BB^ ; 

The ba^c words described above can 
be the building blocks for stAistanttal 
applications. One such application, which 
is particularly useful pedagogically, is 
conf ormal mapping. I have defined a word 
MAP such that the sequefKe 



Conversion words between rectangular 
and polar forms are also very useful. To 
go from retangular to polar, with the 
phase 'in radians) on top of the stack and 
the modulus just below, we have 

t BXAR ZDUP /Z/ FXn mjT ABG^ ; 

A similar word, DPOLAR, leaves the argu- 
ment in degrees. For conversion from 
polar to rectangular, we have RECT (angle 

in radians) 

J BECT FCWER FOVH* CDS FROT FHTT SIH P* I 

and a word DRECT for the angle in 
degrees. A very useful application of 
these is a rotation operator ROTZ, defined 
so that the sequence Z F ROTZ rotates 
Z by F radians and leaves the result on the 
stack. The definition is 

: raa FBOT Wxa four EHJT W* RECT ; . 

There are several different useful 
formats for complex output. C 'y system 
has 8 different f^mats, which is handy 
but a tittle extreme.) The word Z. prints 
the rnumber as an ordered pair 3.5 7.2 , 
for example. The conventional mathema- 
tical notations is obtained by ZI. — (3.5) + 
(7.Z)L Words to print in polar form are 
also useful. For example, ZP. is defined 
so that the sequence 3.5 7.2 ZP. gives 

ttX) ^ 8.005^2303 AR3 - 1.11832144 (BAD] . 

All of these output words are defined in 
terms of the basic floating point print 
word F, , For example, Z. is defined by 

; Z. FSWP F. 2 SMCES F. ; 

The binary complex operations are Z+, 
Z-, Z*, and Z/. These ara quite easy to 



MF<P <curve> <func7tic^> 

will take any previously defined curve in 
the Z-plane and any previously defined 
complex function, and produce a graph 
showing the curve and its image under the 
transformation. This tool allows students 
(and the instructorD to improve their 
understanding of tha geometry of complex 
functions. 

Notes on InvlafnentaUan 

The code described above runs on the 
author's iBK Apple II. The underlying 
integer FORTH is the excellent version 
written by William Graves and distributed 
by SGFTAPF. The real floating point 
arithmetic and functions have been 
implemented by interfacing the SOFTAPE 
FORTH with the Applesoft ROtvt rou- 
tines. The same data stack is used for 
integers (Z bytes), reals (6 bytes), and 
complex numbers (12 bytes). The code for 
the complex routines was written entirely 
In FORTH, and, in compiled form, occu- 
pies about 2K. The conf ormal mapping 
code compiles to about IK additional. 
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A FORTH BASED 
M1CRO-5I2EU 

MICRO asse:m8Le:r 

Gregory E. Cholmondeley 
Laboratory for Laser EnergBties 
University of Rochester 

Abrtract 

The FORTH progrsmming language can 
be used to implement a very small and 
umful micro assembler. FuooCions ranging 
from automatic field alignment to user 
definable macros can be written and 
altered easily, permitting a flexible and 
easy to use microcoding technique. This 
paper also serves to illustrate several of 
the many programming features found in 
FORTH. 

Introduction 

Computer central processors often 
contain an itemal data form called 
"microcode." This code defines the 
instruction set of the processor. The 
creation of this internal code is called 
"microcoding." 

Microcoding by hand is at best a tedi- 
ous and wasteful undertaking where a sig- 
nificiant portion of a programmer's time is 
spent aligning fields, formatting output 
and correcting typographical errors. 
Under standi rig (iet alone debugging) a 
microcode program is difficult due to the 
lack of readability from a human point of 
view. Through the use of comments, auto- 
matic field positioning, labels and other 
such tools, a good micro assembler should 
minimize the above problems making 
microcoding a much more agreeable fcvm 
of programnung. 

There already are micro assemblers 
written which handle these along with 
other problems associated with micro- 
coding, but most of them share one rather 
serious drawbacl<; they are large pro- 
grams. The micro assembler presented 
here is based heavily upon the Signetics 
micro assembler but requires only a few 
"blocks" of FORTH code. Thus it is pos- 
uble to have a micro assembler on a smalt 
home computer[ Such an assembler could 
ba used as a dedgn tool as tMell a« an 
Inexpensive and effective teaching aid. It 
would allow even wide Instruction words 
to be built in a simple to uset hi^ level 
form. 

Usage 

There are two main phases associated 
with this micro assembler: instruction 
definition and actual programming, A 
third phase will he implemented shortly to 
allow the user to explicitly and easily 
define output formats. The first of these 
phases to be explored is the instruction 
definition phase. This is the time when 
Uie various instruction word formats are 



defined. A simple example of such a 
defmition would be as follows; 

nslSTRLJCTION WIDTH 8 

Define an 8-bit instruction. 

FIELD A WIDTH 4 DEFAULT 5 
Define field A as the 4 most rignlfi- 
cant bit positions in the instruction! 
having a default value of 3. 

FIELD B WIDTH 2 

Define field B as the next 2 bit posi- 
tions, having a default value of Q. 

FIELD C WIDTH 2 DEFAULT 1 

Define field C as the 2 least signifi- 
cant bits, having a default value of 1. 

END.1NSTRUCTION 

ClcMe the instruction definition. 

The resulting instruction word would 
appear in the following form: 



1 



4:3 



2:1 



i 



INSTROCTION WIDTH 3J 
FIELD AA WIDTH 8 
FIELD BE WIDTH !6 
FORMAT 

FIELD CC WIDTH U 
FIELD DD WIDTH 12 
FORMAT 

FJEID EE WIDTH 
FIELD FF WlUm 

FORMAT.EKD 



FORMAT 

FIELD GG VFIOIH 16 DEFAULT 6SS3S 
FORMAT . EOT 
FIELD HH WIDTH 8 DEFAULT 2SS 

, END . INSTRUCT10.M 

Figure (1) : Sanple iBStructrat Definition 



iastructiatn 
/ 

/ 

/ 

AA— >6B">HH fields AA, BB and HK 



[ 



■a >A field BB has 2 alternate 

/ I formats 

/ I 

/ I 

CC">VID GG format 1 tains fieldi CC 

I and DD format 2 contains field 

j S6 

* 

I field DD has 1 alteroate 

/ fozoat 

/ 

EE">FF fields E£ and FF 



From this point on tite field names A, B, 
and C will be unique and may not be used 

to define other fields. 

While the preceding example is rather 
trivial an instruction definition may 
becocnc q;jife complex. It is, for instance, 
possible to define nmltiple formats for 
every field, with each of these containing 
multiple sub-fields. This is useful when it 
is deemed that fields should have ilif ferent 
meanings depending upon the context of 
the rest of the Instruction word (vertical 
versus horizontal programming). Sub- 
fields are treated in the same manner as 
fields so that they too may have multiple 
formats and sUb-fields. This feature Is 
implemented as a tree structure allowing 
an unlimited nesting of fields, formats and 
sub- fields. Figures (1) and (2) should 
clarify this concept. 

This part of the micro assembler has 
error checi<ing capabilities which prevent 
unintentional overwriting of fields. For 
example, if field EE of figure (1) is filled, 
then fields BB, DD and GG (and of course 
EE) could not be used. Automatic field 
defaulting uses the same mechanism so 
that if field EE is the only fleld flUed 
(using the format from the previous 
example) than field* AA, CC, FF and l-UH 
will be defaulted. 



Figure (2} : Stxucturs of Figure (1) 



The programming phase of the micro 
assembler is where the actual microcoding 
takes place. An instruction is created by 
typing the name of a field followed by a 
number or expression representing the 
value that that field should take. This is 
continued for as many fields as needed in 
the instruction word. When the instruc- 
tion is complete a "$" (dollar sign) is typed 
and the computer readies itself for 
another word. At this point any undefined 
nelds are set to their default values, the 
instruction end other related information 
is stored in memory, and the location 
counter is incremented. Figures (3) and 
(4) demonstrate a simple microcoded pro- 
gram which merely sets one field at a 
time equal to s zero. 



ntOGRAH 1EXAMPI£ WIDTH 32 
C»tG 512 



DEFAULT 255 

DEFAULT 65S3S 

DEFAULT 15 
DEFAULT 4095 

DEFAULT 1023 
DEFAULT 3 



AA 

Bfi 

CC 
DD 
EE 
FF 
GG 



END. PROGRAM 



Figure (3) : Sewple Frogcan 
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used 


BB 


& HH defaulted 


EE 


used 


AA 


S. HH dcfaultod 


CC 


used 


AA, 


DD ^ HH defaulted 


m 


used 


AA, 


CC k HH defaulted 


EE 


used 


AA, 


CC. FF i HH defaulted 


FF 


used 


AA, 


CC, EE & HH defaulted 


GG 


used 


AA 


& HH defaulted 


HH U8«d 


AA 


& BB daf«ultsd 



While automatic field alignment is in 
itself a vast improvement over hand 
coding, there are a few other tools avail- 
able to the programmer which make 
microcoding even easier. A "(_*' denotes a 
comment allowing anything up to and 
including a ".)" to be ignored. Typing ORG 
and a number or an expression will set the 
location counter ( LC ) to that value. 
Typing sex <new variable naitie> 

TO <number or express ion> 
will dectaire snd initialize s variable, while 
typinQ EQU <old variable n«B*>' 

WITH <iiuab«r or •xpic«*sion> 
will store a new value into a previously 
declared variable. These variables return 
their value when they are typed (similar to 
a constant in FORTH-O and can be used in 
expreBsions at any time and in any phasa 
of the micro assembler. 

One of the most versatile tools avail- 
able in this micro assembler is the 
MICROP function. Microps are user-, 
definable functions designed to eliminate 
a iarge part of the repetitious program- 
ming associated with microcoding. For 
example there may be times wiwn several 
fields will always take on constant or 
relative values. Rather than cluttering 
the program by having to aet all of theae 
fields every time, a mi crop can be written 
to do this automatically. A program writ- 
ten using well named microps can in turn 
be quite a bit easier to read and under- 
stand than one which merely sets the 
fields. 

The definition of a microp requires a 
unique name and a set of commands which 
will be executed whenever its name is 
called. Any FORTH programmer will soon 
realize that a microp definition is nothing 
Other than a colon definition, thus allow- 
ing the full power of FORTH to be eaally 
acoeesed directly from the micro assem- 
bler[ An example of a ^mple microp that 
■ats a few fields to zero would be; 



MICROP EXl C. set fields CC, ¥F, 
CC and HH to .) 

FF 
HH 

END. MICROP 



Elgure (4) : Sample Output 

An exarr^le of this microp in use would be 
found in tlw programming phase and might 
look like: 



AA 7 HH ( LC ) $ 
AA S EXl $ 



NOTET: LC in the precedirq example is 
a variable, the "(" and ")" are required 
for its proper execution. They do not 
denote a comment in the MICRO 
vocabulary context. This is also true 
when building microps. In the MICRO 
vocabulary comments are delimited by 
n." and ".)". 

Being ^mple colon definitions, microps 
cen do internal testing, looping and every- 
thing else off wed In FORTH. Microp* can 
expect parameters on the stack aa well as 
numbers or expressions from the input 
buffer via a function called QET#. For 
example: 



Another way to increase readability in 
the micro assembler is through the use of 
labels. This feature is only partially 
implemented at this time but will work as 
follows. Labels must have unique names 
and must be declared via LABEL state- 
ments before they are used. When a label 
is found immediatety preceding a new 
instruction word (or in other words; 
immediately following a '%") the current 
value of the location counter ( LC ) la 
stored as the value of the l^aL Multiple 
labels may be used to represent the aame 
line of code. When a label is uaed inside 
an Inatructlon definition after Its value 
has been set, it will be treated as any 
other variable. If the label ha^ not been 
set to a value (i.e., forward referencing) a 
zero will be returned and alt information 
necessary to resolve the reference will be 
stored in memory for the second pass. 
During the second pass the micro assem- 
bler will shift the correct value(s) of the 
labeKs) into the proper placets) and then 
add the resulting number to tl-te rest of the 
word. This allows labels to be referenced 
mon than once in a single instruct! oru It 
also allows addition and subtraction of 
other non-label expreselons to labels (I.e., 
AA C ILABEL 4- 2 } or AA ( ILABEL - 1 ) 
but not AA (1024 - ILABEL ) ). When this 
Is implemented another extended precision 
function ( E+ ) will be needed to perform 
the extended precision addition. 



HI CROP ?GT 
GETff > 
IF AA 
ELSE HH 
THEN 

END.HICROP 



C. <exprl> ?CT <expr2> -- tests If exprl is > expxZ .> 



B6 



CC 

) 



This could be used like: 



AA 19 $ 

<variabIe.iiaBe> 7GT 1024 $ 



Finally, microps have macro capabilities 
in that they can be nested and may even 
create several lines of code in one call (as 
may be needed in a test and branch, or 
jump substitute routine). 



mCSOP EX3 

LC 100 > 
IF EXl S 

LC ?GT 1000 
ELSE AA $ 

CC HH 

THES 
END.mcBOP 



The last major feature of the micro 
assembler concerns output formatting. 
This has not been developed at alt but will 
corisLst of a basic instruction set for 
programmers to use to define specific 
output formats (i.e^ hex, insertion of 
special delimiting characters, etc.). The 
programmer will define a function (similar 
to a microp or colon definition} for each 
type of output fomat. The executable 
code field address of the current format- 
ting function is stored along with the 
other instruction word infDrmati(xi on the 
first pass. On the second pass the format- 
ting function will be executed to produce 
the desired result. It will be ppssible to 
change the current format function 
between instruction words by using a 
command of the form: 

SET. FORMAT <format f miction name> 

allowing multiple output formats within a 
■Ingle program. By installing different 
formata In currently existing ones, it will 
be poe^bJe to view the code in punched 
card format as well as a format suitable 
foe blowing PROMs! 
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Implementing Techniques 

The first problem that I addressed was 
how to align the fields in an inatruction 
word definition. For words that are J2 or 
fewer bits wide the solution is simple, 
merel)' do logical shifting and ORing. 
Since 32 bits is a rsthor stringent limit on 
the MTOTd width, I have l<^t the Mme batic 
strategy but have defined a set of func- 
tion* which can do logical operations upon 
axtencted precision words. Ttie (nvclslon 
(In terrra of 16-btt words} is stored in a 
variable celled PRECISION and is set at 
the PROGRAM WDTH statement. These 
are the extended precision functions which 
Ii 



1. EXT.PREC - This is a defining 
word that creates an extended 
precision variable which uses the 
Bartholdi "TO concept" to store 
and fetch extended precisian 
numbers. EXT.PREC expects the 
detired precisian of the new 
variable on the stadd 

Z. E.FILL - E.FILL exp»ct« a number 

and the precision of that number 
in terms of 16-bit words on the 
stack. It uses this to fill in the 
most significant places with zeros 
until the number has a precision 
equal to the current value of 
PREClSiON, Notice that the 
value of PRECttSION must be 
larger or equal to the length of 
the given number. 

3. EJ>ROP - This function dHipa an 
extended precision number from 
the top of the atadt. 



*tt*»tttt*ttt«>ttt BLOCK iiO 
I aliebrsic notation GEC 



t*t«st»tt*mtt*t*» 

15-JUL-81 I 



i UETi t E<,> — <input exrrattion't value.'] i 
32 HORD HUtlBER HOT ' ( aet next tnput chsr/mi* J 

IF lt> R> SHAf >R >1t THEM t < If chsr than trest «s > 



( . 



CCOhiPILE] ( i IHItEDIATE 1 define C. coiment dvllBlter ] 



UOCft£iULfiF;) MICRO 
+ GtTf + ; 
- GET* - i 
» GETt % > 
/ GET* / t 

> R> R> SUAP >R >R i 
( t I 
FORTH DErittlTIONS 



t»*tt««tS««t«t*t>» BLOCK 
< value sttd fli^rloF tupes 



KltftO [lEFIMHlONS 

(. C<*1> — <*1 + reaefme + .J 

(. l<tj> — '*1 - i2,'l redefine ~ .1 

(. [:sll>---.li t tJ.] -eaefjne * .1 

it £*l#l/"^tl / reaet irte / tt 

It — '...'Z end e:<presoiori .J 

(. L<.:> — 01 stsrt eMPression >i 



161 *tt*St*l:»f»tttttttt 

SEC lO-JUN-Sl ) 

TO 1 !;to > i 



UAL ( returns value of variable I! not address i > 
<6UILIiS . DOES> 

ITO e IF } ZTO ! ( store value ) 
ELSE B I Push value ) 

TKEK i 



! FLIPfLOP ( returns 0/1 and stores 1/0 ) 

<6U!LtiS t ( [<>—'.>] initialise F.F 1 

IitlES> ITO e 
IF ! 270 ! 

ELSE SUP t SUP I4DT SOT ■ 
THEH I 



( C<l/0>— <>} set F.F. ) 
( t<>~<l/0>] flip F.F. ) 



**mtt>m*tmtt block 
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( 


variable definitions 


BEE 19-JUM-Bi ) 







UAL 


CUR.AHBF 




( currant Kddress 


> 





VflL 


C.FIELB 




( current field 







UAL 


C.FORn 




< current format 







UAL 


C.IWSTR 




I current instruction uorrt 


) 


D 


UAL 


F, LENGTH 




( field lena-th 







UAL 


F.POS 




I field position 


I 





UAL 


LC 




( location coijnier 


) 





UAL 


It«ETKUIDTH 




I intiruciion width 


> 





UAL 


l.FIELB 




^ last fib'lo 


I 





UAL 


L.FORtt 




i last fornat 


) 





VAL 


L.IHSTR 




( last instruct 1 en 


) 




ML 




( 


currant ■tiOrM tddr for print routines 


> 





VAL 


NEU.UORD 




{ flsa set ft start of neu instr. uord 







VAL 


OFFSET 




< offset of ehtft <used in ESL} 


> 



4, ESL - The ESL fijfiction performs 
a logical shift to the left on an 
extended precision number. It 
expects the extended precision 
number and the number of shifts 
on the stack and returns the 
shifted number. 

5. EOR - This takes two extended 
precision numbers off of the 
stack, iogically ORs them togeth- 
er and retuTitt the resulting 
numbK*. 



««tt««>i*ttns»*»» BLOCK 



U3 



von 
UAL 
UAL 
UAL 
UAL 
UAL 
UAL 
UAL 
UAL 
FLIPFL 
XEO 

X£Q 
XEO 



able definitions - 2 
O'JFLt 
PLACE 
PRECISION 
TESI.FLAfi 
TSHIFT 
XDEF 
51FLA6 



GEC 



19-JU«-81 ) 

( overflou flaa ) 

( addr of temp ^tora^e in e::tefid^d of-e rations > 

I precision of word in It tit units ) 

< flaa used m error ciieci"inS arid defauHifiS ) 

1 ioter»ediate number of shifts ■tESL> 1 

( default Phase {0. use/1, set/ 2. initta]i::e> i 

< value to store in flaas -10/ 1> j 

iPRINT .FORMAT ( addr ot output foroat code > 
OP FLB.FF ( field F.F. fur errcjr checi(in3 t defsultin3> 
BROTHER ( brother of current field/foraat ) 
PARENT < parent of O.FULK ) 
SELF i C.FIELD > 

UNCLE ( uncle of C.FIELD ) 



6. EXOR • Thle executes an exclu- 
sive OR operation between two 
extended precision numbers. It 
expects two extended precision 
numbers and returns ttie result* 

7. ECOM - ECOM does a I's comple- 
ment of the given extended preci- 
Hon nunibar. 

One extended arithmetic function will be 
needed to implement forward referencing 
of l^ials. This function has already been 
mentioned and will be called E+. 



t**t*****Utttttt* BLOCK 1«4 
t extended precision functions GEC 



12-JUN-Bl I 



EXT.PREC i .precision.'--,' builds an axtended precision 4 ) 

<BUILDS EiUP 2* r [10 , LOOP 

DOES.> ( <^-'xlow-orde r ... hi^h-order/ or reversed if XTO > 
IiUP DUP e + 2 * SWAP 2 + 

ITO e IF Oa 1 ! 2 fLOOP !T0 I < stores i ) 

ELSE SNAP 2 - BO I e -2 tLODP ( fatchvs t ) 
THEN } 

E.FILL ( <* lenWt 0> i>utE O's in hish order places ) 
PRECISION SUAP 3DUP > IF BO LOOP ELSE 2DR0P THEN t 

EOROP ( <l0M-order hiah-order>'<> drops ext. precision t } 
PRECISION 6 BO DROP LOOP I 
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When 3 field is assigned a value ami is 
aligned, the following process occurs. An 
extended precision number with a preci' 
sion equal to PRECISION is on the stael<. 
This is the value of the current line of 
mjcrocode. After the field-name is typed, 
an extended precisim number with a 
precisiofi equal to the width of the field is 
accepted, E.FILL is used on this number 
to make it the Rame precision as the 
instruction word, ESL is used to shift it 
over the proper rijmber of bits, and EOR 
is used to update the mi era -instruction. 
This is ripBat«d until a "t" is encountered 
which will cl«sr the flags, set any default- 
ed fields, store the extended precision 
instruction word in memory and leave an 
extended precisii»^ number equal to zero 
on the stack (for the next micro- 
inttruction). 

The second main problem that I faced 
dealt with hov/ to handle multiple for- 
mats. I implemented a tree structure 
where the instruction is the root with the 
list of fields as its children. Eaofi field 
has a list of formats or a zero for its 
children. Every format has a list of fields 
as its children and the cycle continues. 
Each node in this tree has pointers to its 
parentt 'kildest" chiidi, and next youngest 
brother. Each node sleo containt a flag 
denoting whether it is a valid field or not, 
a value corresponding to its starting posi- 
tion in the instruction word, its field 
length and its default value. Thus when a 
field is accessed a test is executed to 
determine whether it is valid or not. This 
is accomplished by traver?;iny up the tree 
and checking the validity flag. !f the first 
set flag is found in a fieic, then the 
programmer is trying to overwrite another 
format in the same field. If no flag is set 
and this is not a new line of tnicrocode, 
then this field is not defined in the same 
instruction word » the previous one(s) and 
anothM error condition is found If, how- 
ever, the field is determined to be valid, 
then the flag bit of that field will be set 
along with the flag of its parent, and its 
parent, continuing tip to the root. When a 
"i" is encountered, the tree is traversed in 
the same manner but from the root down 
and all flags are reset. At the same time 
any unused brothers of the Inweat level 
fields used will be assigned their default 
values. 

INSTRUCTION FORMAT FIELD 

INSTRUCTION FORMAT FIELD 



0/1 



Parent | 
Brother j 
Used Flag ! 
Child I 
Field Starting Position 
Field Length 
Default Value 
or Zeros 



I I field I ) format T 
I i " format 1 | field 



J 1 I I "/I 



field I i field | i format 



L - 



**««t*tm*ttmt> BLOCK 165 «t*tMi«ttmtt«tti 

! Ul'^l'^fi ^'^''•^ functions - 2 GEC 12-JU«-81 ) 

, *-shitts to left <dPo« hish ov t <.hiff> in 0'5 > 

" 2 « ♦ TO PUCE H£F.L 

f-RECISION 1 - 21 BO 1 TO OFFSET KUP TO TSHlfT sLftP ' 
BEGIN tSHIfT ii * ^° '■ 

" OFFSET 2 f IQ OFFSET ' " ' 

TEHIFT li - TO ISHIFT 

r, =r ' ' set overflou fl#< ) 

^'Ih, 1SH1F7 <-L ^F/ilF'^E^E' ' """'^^^ ' ' 

SUP e ROT oa snap i 

— > 



( extended prsc. functions - 3 GEC 12-JUK-ei ) 

OFFSET 2 + HERE 1 liuF ? ( handles ts that are split ) 
ROT 16 rSH!FT - -, L OF: SWAP ! { into 2 bsttf bv Shift I 

THEN Ok^FLG NOT TO DWLB 

-2 4LU0F' DROP 

PLACE HEKE DO I t 2 +I.ODP ( ( fetch * froK taap uorkfpice > 

J ?PRECISIOH < Ct Of bits3--E# of 16-bit MordsJ » 

17 N/HOO DROP SUAP DROP if i 

t E6ET C £<addr of variable>— <e):t.rre.4>] ; 
nUP PRECISIOK i - 2* + BO I e -2 +LOOP J 



tfft|fltrtt»*»tj[t»f FLOCK 
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( extended s»rer. fijnctions - 1 GEC l'j-JUf(-ei i 

i EOF" ( veMt.r-re.t e>:t.f-i-s.t — er.t .pre ■%> ilh 2 e;;t.Fre ) 

HERE PKECISKjN I'* + 1 - DUF TO PLACE HERE DO I ! 2 +LOOP 
1 FRECISlGfJ [<D 

I PRECISION + PRECISION I - + PICK 
PRECIS lOM 1 + FICK OR -1 +LOOP 
HERE PLACE HO I » ~2 +tOOf 
PRECISION 2* m bfdjv LOtiF 
PLACE HERE 1 P i +1.00F ; 

; ECOtt ( C<e>!t.t^"<NOT e>:t.tx^l one campleatnts eiit.pre.t ) 
HERE PRECISION 2« + 1- DUP TO PLACE HERE 
SWAP DO I > -2 +L0OP 
PLACE HERE DO I ? COM 2 HOOP i 



ERROR. FUNCT 



ERROR code: 



CR 



t*ttl:ftm***«t**t BLOCK 
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( extended prec. functions - 5 GEC ;5-JUf<-Sl / 

I EXOft ( <e^.t.f're.t e>:t.pre .*. -\ei;l . p re.* Ok 2 e;;t.fie ♦< 
HERE PRECISIOK 3* + 1 - DUF TO FLACE HERE DO I i 2 +LOOP 
1 PRECISION UO 

I FFECISION + PRECISION I - + PICK 
PRECISION 1 + PICK KOR -1 +LOOP 
HERE FlACE do 1 ' -2 tLCOP 
PRECISION 2t DO DROP LOOP 
PLACE HERE DO I 8 2 +L0OP i 



ttlttttHtitttl***** BLOCK 
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tttttittttttttt.*.*.** 



6EC 



( offsets in field struetupe 

J OFF.VAL 

+ no 9 IF ' XTO ! ELBE DUP 0<>- IF S THEN THEN i 



3-JUL-Bl ) 



?PAR£NT DFF.Vftl. i l TERDTHER 

?FLAG 1 OFF.VAL * ; TCHILD 6 

?ANCEETOR 'fPARENT ?PfihENT i 
'INSTRUCTION. WIDTH 8 OFF. UAL i 
7FIELD.STAR- C.FlELt 8 OFF.VAL ( 
?FIEf,B. LENGTH C, FIELD U> OFf.UAL I 
TBEFAULT C. FIELD 12 f i 
NEW « SDK 

OUP'?CHILD DUF ROT AND 

IF SWAP BEGIN DUP ?iROTHER ROT 
ELSE DROP (I 
THEN TO BROTHER ; 



2 OFF .VAL 
OFF.UAL i 



INsTRtlCTlOti 
FIELD 
FIELD 
FIELD 



DROP DUP NOT END DROP 



FORTH DIMOMSIONS HI/* 
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With the structures defined, the task 
of creating a program comes to light. An 
explanation has ai ready been given des- 
cribing how the words are constructed. 
The following diagram should help clarify 
how 3 "program" is actually *tored in 
memory in its first pass form. 



utttttttttttttttt itacK 



General First Pass 
Microcode ProQrafn$ 



Forth 
Header 



Prograo 
Header 



Complete 
First Psss 
Data For 
On« 

Instruction 
Word 







1^ 



Structure for 



Forth 
Name 

Link 

Dcscr ipt ion 
Instruction Word Width 



Address of Label 

Field (le. # of chifts) 



Address of Label 
Field 

Output FocBat 
LC 

Instruction 
Word 

Address of Lab«l 
Field 



Instruction 

Word 
End of Progratt 



Each program has a unique name which 
dsrinea a F^TH tieader. When this name 
is typed, the program is listed in a liasJc 
binary and hex form aiong with the format 
address, LC, and any unresolved labels. 

One of the primary objectives of this 
micro assembler is to make microcoding 
easier by making it more readable, and 
there are quite a few places where the 
reverse polish notation found in FORTH 
does not appear quite as nice as an infix or 
prefix form. Hence, 1 have written a few 
short functions to allow FORTH functions 
to accept numbers and expressions from 
the input buffer as well as from the para- 
meter stack. 

This method uses the return stack via a 
function GET# which accepts input from 
the input buffer. If the input is a number 
GFT// places it on the stack and returns. 
If the input is not a number then GET// 
assumes that the programmer typed a left 
parentheses "(" meaning that there is an 
expression or a variable in the input 
buffer. If this is the case then GET// will 
swap the last two values on the return 
Mack and return. When a right parenthe- 
ses is found, the top two values of the 
return stack are again swapped and the 
system is back to ncnmaL This is simple 
wvd fast, although it has no method of 
checking whether a sat of parentheses is 
IMtipwty closed. However, a variable 
could be used which would be Incremented 



171) smu»s*tt(tm**t 

3-JUL-Bl J 



< headers of fields t forsats G£C 
! THAHE mf 0<> IF CFA THAHE ELSE DROP THEH i 
: IGNORE 32 UORIi DRQP i 

: HEADER < creates 1st 4 fields in FIELD »ftd FOftHftT i 

TO UMCLE HERE TO SELF 
BROTHER 0<,- IF SELF BROTHER TO ^tROTHER 

ELSE SELF PARENT TO ^CHIl[: 

THEN SELF TO UROTHEf! 
PAfiENT J I I I ! I parent/hrotfier/f l39/child ) 

: rORWAT.HEAKER ( defines FOftKAT relatives t e:<ee.jtes HEADER > 
INSTALL L.FIELD IH UHCLE INSTALL C. FIELD IN RAKEMT 

INSTALL L.FORK IN BROTHER INSTALL C.FORH IN SELF 
C. FIELD NEU.SON HEADER TO C.flEU i 



tm*mittttttU» BLOCK 171 

( inslrucliori and forast defs. GEC 



tttm*m««*>tst*> 

3-JUL-81 > 



INSTRUCTION ( INSTRUCTION <n3»(?,- MIPTH <ui6th> ) 

TO C.FIEiD FORHAT. HEADER 

IGNORE SET* , . , . , 

nijp , { instruction uidth ) 

DUP TO F.LEMQTK TO F.POS ! C field lenath'f neid fositior, ) 

FORMAT ' FORMA: > 

7FIE1.D. LENGTH TO F. LENGTH ( field lenjth f 

'FIELD. START F. LENGTH + TO F.fOB ( field »sUlon ) 

FORMAT. HEADER i . _ ^ . . . 

SET. FLAGS ( <*>-<> »ets flsss froi C.FIfLD to » ) 

TO li^FLAG 

iEeiH''?PflREHT XFLAS TO OVER ?FLA6 DUP HOT END DRQF 

XFLAS C, FIELD TO 7FLAG ! — > 



ttt*^*ttttt**%tt^^* DLOCK 
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GEC 



3-JUL-ei ) 
( END.FORIIAT 



( foraat.end and field header 
: FORMftT.END 
C.FIELIi TftMCESTOR DUP TO L .FIELD TO C. FIELD 
C.F1EL& ■'FflRENT IF 7FIEL0. START ELSE THEN F.POS <> 
IF 2 ERROR. FUHCT RESTART 
ELSE TFIELD. LENGTH TO f .LENGTH 

TFIELD. START TO F.POS 
THEN i 

t FIELD. HEADER 

INSTALL L.FORH IN UNCLE INSTALL C.FDRft IN PARENT 

INSTALL L. FIELD IN BROTHER INSTftLL C. FIELD IH SELF 
SELF 0<> IF SELF 7PARENI ELSE C.FOKM THEN 
OyP TO PARENT HEU.SON 
HEADER i —> 



«t*t*St»*Wtttt«tt BLOCK 
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( error eheekini for used fields GEC :i-JUL--rii ) 

: ER. CHECK ( check to see if field is ferriitte'i 

TO FLD.FF C. FIELD 



BEGIN 

[lUf TfLflG TO TEST. FLAG 

FLD.FF tiROF' 

7Ff(RENT 

DUf NOT TEST. FLAG OR 
END DROP 

TEST. FLAG FLD.FF AND 

IF * ERROR. FUNCT RESTART 
ELSE TEST. FLAG HOI 

IF S ERROR.FUNCT RESTART 

THEN 

THEN TO TEST. FLAG i 



i set TE£T.FLfiG=FLfliS ) 
i flip field. flip. floF- ) 
' 30 to f'Srent ) 
( if flaa found or root reached^ 



( field defined t«ice > 
( not proper instruction ) 



( defaults 
: DO. DEFAULT 

TflELD. LENGTH 'PftECISIOM 

KDEF SEL 
« 2 == 
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6EC 



8-JUL-ei > 



DROP BD p LOOP TO » 

« 1 ==> DROP E.FILL ?DEFflULT ?F IELD.LENSTH 
TPRECISION OVER + 2* SiitiF 
DO 1 ! 2 4L00P TO SDEF ,>> 
« ==> DROP ^IiEFftJLT SWAP 1 - 2* CIVER i 

HQ I ? -2 +LOOP 7FIELD. LENGTH *PRECISIOH 
E.FILL 7FIEL0. START ESL EOS » 



EHSSEL } 
TO.DEF 1 TO ZBEF t 

DEFAULT 

GET* TO.DEF DO. DEFAULT i 



INJT.OEF 2 TO iDEF i 
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when a '^" is encountered and decrernent- 
ad when a ")" is found. This would catch 
any errors Involving too many closing par- 
entheses. A "]" function could be written 
which would behave in the seme manner ss 
the UCl LISP function of the asme name. 
It would use the varied^le mentioned above 
to close ell open parentheses for a suc- 
cessful evaluation of the expression. 

GET// and its related algebraic func- 
tions have some interesting features in 
that there is no hierarchial ordering of 
functions (i.e., 2 + 5 " 5 - 25 while 5 • 3 ■* 
2 = 17), however, Px^iressioris eiclosed In 
parentheses will he solved before others 
(i.e., 2 + (J * 5) = 17). The entire code for 
this is only a few lines long and is as 
follows: 

: am 32 VORD NUHBEIt 
KOT IF R> R> SWAP >R >R 
THEN 1 



( field stfueture 



175 tUttttttttittttttt 
SEC 3- JUL -81 } 

( FIELD <n3ee> WIDTH <uidth> ) 



VOCABULMty ALGEBRAIC ALGEBRAIC DEFINITICKS redefine fiinctions 



; + GZTii + ; 
: * GETJ.i ; 
: } R> R? SWAP >R >R 

•■(.): 

FORTH DEFINITIONS 



- GET# - 
/ 6ET# / 



t FIELD 
<t!UIL[iS IGNORE GET* 
DUP F.LEMSTH <- 
IF FIELP,HEfl!>Efi 

F, LENGTH OUEft - TO F. LENGTH 
F.POS OVER - DUP TO F.POS 

f • ( field stert/field lensth ) 

INIT.DEF DD.PEFAULT 
ELSE 1 ERROR. FUNCT RESTftRT 
THEW 

DOES. TO CFlELIi 

HEU.UORD IF TO NEU.UDRD ELSE ER. CHECK THEN 1 SCT.FUGS 
GET* TFIEIP. LENGTH ?FRECISIOH E.FILL 

TFIELD.STftRT ESL EOR ! ~-> 



FORTH-like, It does result in much 
cleaner code. I adapted the concept in 
one place to build a flip-flop function. 
This function creates a data type which 
alternately returns zeros and ones when- 
ever It is called and maizes use of the "TO 
concept" to allow itself to be initialized to 
either state. The micro assembler also 
makes use of multiple vocabularies to 
allow the same function to have different 
meanings in different contexts. While this 
is not absolutely essential for the assem- 
bler to run, it again makes the code 
cleaner and easier to use. 



gets number 

swap if not e. number 



re -swap returit stack 
swap return $ tacit 



be: 



A typical usage of Uils function could 



{+} GET# + ; 





3 {+) C 4 


{+) 5 } . 








12 








Current 


I 


Parameter | 


Return 




Fun et ion 


1 Coimiand 


Stack 1 


Stack 








main 


1 3 


3 1 




input a 3 


{+> 


1 {+) 


3 1 


main 


call function {+) 


GETS 


1 GET# 


3 1 


main {+) 


call function GET# 




1 c 


3 1 


{+} main 


swap return stack 


ma in 




3 i 1 


{+} 


return and input a 4 


{*) 


1 {+) 


3 4 1 


{+} main 


call {+} again 


GET;; 


1 s 


3 4 5 1 


{+) main (+} 


Input a 5 


{ + ) 


t + 


3 9 1 


{+) main 


return and add 


main 


1 


3 9 1 


{+) 


retutn to «altt 


) 


1 > 


3 9 1 


{+} nain 


call function ) 




1 


3 9 1 


main 1+} 


swap return stack 


{+} 


1 + 


12 i 


main 


return and add 


nain 


1 






return and print 



There are a few general concepts 
which are used throughout this micro 
assembler, one of which is the "TO con- 
cept" (see Joe Sawickl^ paper entitled 
Optimized Data Structyres for Hardware 
Control}. This concept allows the u» of 
variables without the programmer having 
to deal directly with the address. White 
this may be thought of as beinq a bit un- 



Concluaian 

The reason why 1 have chosen to write 
this micro assenibler in FORTH is simpli- 
city. As 1 mentioned earlier, this "pi""* 
gram" is based largely upon a very lengthy 
micro assembler written by Signetics and 
yet the FOP.TH code is only a few pages 
long. The time spent programming was 
equally short. It took roughly half of my 
time at work from around June IQ through 
July 15 to complete the micro assembler 
to this point (although 1 have occasionally 
gone ttack to add or change a feature or 
two). Twc of the features that I did 
change, labels and forward referencing 
through the fint pass, brought up another 
quality of FORTHj its modular nature. 
Thsse are rather major additions and yet 
they only required one new "block" of 
code, a few rninor changes in the old coda 
and took only a few hours to implement[ 

Once the forward referencing is com- 
pleted and the output formatting is imple- 
mented, this code will be a micro assem- 
bler by itself as well as a kernel for more 
extended versions. An exaniple of an 
extended feature is the compilation of a 
symbol table at the and of a program. A 
further extension would involve tyirig this 
symbol table to other symbol tables to 
allow external references. Throu^ the 
use of extemat symbol tables the micro- 
code could be maintained in the first pass 
format so ttiat the external references 
could be resolved several times for labels 
with differing values. This could result in 
a modular microcoding technique. 
Another extendon coutd be a FORTH pro- 
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gram which would be used, in much tfie 
$arTte manrfer as the cnicro assembicr^ and 
similar to Hardware Description Lang- 
uages, to desrribe a simulator for the 
microcode. These two programs would 
conatituto a poworful yet inSKpentive 
teachir^ aid as well aa an effective design 
tool. Prografnmen and students would not 
need to waste their time pundiing carda or 
blowing PRDMb in order to discover the 
eiTors In their code[ A dozen other "nice" 
features can be imagined (i.e., prohibiting 
forward refcreficing to allow interactive 
microcoding, or the development of intrin- 
sic mlcropa to define commercial chips, 
etc.), but the point is that they could all 
be based around the small "kernel" mioro 
assembler presented here. 
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t*t(ttm«*m**» BLOCK 176 *t«t*««SM*»«l«tt«t 

( end,ir,str I find root t brother 6EC li-JUN-8! ! 

: EMD_INErHUCTION ( checlts for ar.y ^jcdef ined fields ) 

BEGIN I^ORMAT.EHIi CflELO TAHCESTE9R NOT im> ; 



ROOT SUAP 
BEGIN 

OUP TPflRENT ROT DROP DUP MOT 
END DROP r 



( Tinas instruction > 
< Zt selfl—Cseir parent} ) 



i FIND. BROTHER SUAP 

beg:n 

PUP ?fiROTHEft ROT DROP 
OVER ?FLAG OVER NOT OK 

END DROP DUP 

?FLAS NOT IF DROP THEN i 

tt$9t*Un*MtW** BLOCK 177 



( finds brother uith flas set ) 

^ C« selfj — Lself brothtrJ > 
( flaa OR not brother ) 



( Cbrother OR 1 ) 



{ default - 2 6EC 

: DEFAULT 1 

C, FIELD ROOT DUER TO TFLAG 'CHILD 
BEGItl DUP TD C.HELD 'FLAG NOT 
IF M.OEF - - - 



8-JUL-ei ) 



_rFflULT C.FIELIi VW TBROTHEft ( no fU« SSt-defsuIt) 
C.FIELD Cfi ?NftrtE .' HEFAULIED * 
ELSE C.FULU OVER TO 'FLAO > flaa set-reset to 1 

DUP ?CH1LD FiND.SROTHER DUP I find =.jD-t<;rii,il uifed ) 
IF OUER TO ?FLfl6 ( reset forsst fUs to ) 
7CH1LD ( chscK sub-fields, i 

ELSE [iFiOP DUP 7BR0THER ( no foraat ussd-ftnd brotfieri 
C. FIELD CR ?NAnE .' USED' 
THEN THEN DUP MOT 

IF BEGIN DROP r ANCESTOR DUP TBROTHER OVER NOT OVER QR END 
THEN SUAP NOT 

END DROP CB » — > 



I«tS«»t««*ttStt»S BLOCK 



178 



( Biicro-asiBsbler! forward ref. SEC 17-JUL-ei i 

: LAdEL ( LABEL <ciSBe> ) 

^BUILDS 

f I { iSef .f U3 / vsl ) 
BOES> NEM.UORD 

IF PUP e IF .' Label previousln defined' CR RESTART THEN 
! OUER ! ( set flaa ) 

;+ LC ! ( set value > 

ELSE I>UF e 
If 2t (? 

El5E 'fIELI>. start 6HAP t t 
THEN THEN i 



ttttltxttttltxtttt BLOCK 

( end of ijorrj i oriain 



C. FIELD ROOT IF DEFAULT! THEN 



— > 

8EC 11-JUN-ei ) 

< ends yord in rro^rsi node > 



ZPRINT.FORHAT t LC OOP 



PR|Cp|^^^0 DO DUP B. r LOOP CR 
I TO NEW. WORD i 

ORG 

BET* TO LC ! 



( end of labels ) 
14 TO LC 



m»*t*tt*«**Mt«t BLOCK 
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SEC 



< printins routine 
: U.ZERO 

DUP 1096T U>= IF or 

ELSE UUP 256T ll>= IF IT 

ELSE DUf 16T U>= IF 2T 
ELSE 37 
THEN THEN THEN 
DUP IF DUP DT DO OT IT U.R LOOP THEN 
4T SUAP - U.R f 



I8-JUN-31 ) 
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»»«ttttttttt*»l>t)i SLOCK 181 
' PTintina rautlncs - 2 EEC 



ttmt««m(t>tu(« 

16-JUN-tl ) 



tPftlHT t <e>!t.i>re.t.3d4f>-<> ^rint eKt.i>fe<t iri birttrii X hex > 
CUP PRECXSiaH 2T t f SHAP SDUF SO I B. 2T ^LOOP 
.* ! * BO I t U.ZERO 2T +LODP I 

HEH.IHC KEM DUP 3+ TO HEH B ! 



«l(|[timil*itt*tt*l BLOCK 



182 tltt»«*»»«««««lt»li 
QEC li-JUN-Bl ) 



1 friritifis routines - 3 
: l.FASS.fRJNT 

DUP TO hEK 9 I AND 

IF .* ERROR - PROGftSM LENGTH * CR 
ELSE lo fi^tSE ! CR BEGIN MEK g 
IF PEGIN 

LABEL : • HEM DUP S CfA THAME CR 2+ TO HEM 
.* shifted: ■ HEM DUP e . GR CR 2+ DUP TO HEH I NOT 
END 

THEN NEH 2* TO HEH 
format: ■ MEK HUP e , CR 2+ 10 MEM 
IC ! • HEH DUP e . CR 3+ 'n «EM 
HEM tPRIttT CR MEH PRECISION 2» r TO MEM 
CR CR CR M£H e 1 = END CR lOT EASE • 

THEN i — > 



tttittmttmattt block m 

( prearak ststeaent GEC 



16-JUN-81 ) 



PROGRAM 

;fUILL:S IGNORE GETI DUP » 7PRECISI0H TO PRECISION » 

! TO WEu.UORD 
1 E.FILL 

does;- dop e ?PRECTSiaH to precieidn 4 t i. pass. print i 



tttttitttttttttttt BLOCK 



1B4 



( end f>ro3r3* S Micros coakands GEC 
; END. PROGRAM 
EDROP 1 > f 



ttttt%t%%n**Ttt*ttt 

17-JUM-81 • 



HICRC*F- [COMPILE] : : 
END.rtlCROP CCOMf-ILE] 



IMMEDIATE 



SET 1 defines 3 variable data tape ) 

<BUILDS IGHORE GET* i ( SET <vdr.na*e> TO <«xrrt»iort> ) 

DOES> e f ( <v»r,n*^«> rtturns value ) 

EOU < EOU <wBr,n3>ie> yiTH <expreS5i0n> ) 
)'E IGNORE SET* SUAP i ( 



MICRO DEFINITIONS 



NXJSTRYNEWS 

rORTH-Bated Savvy Lets Usw 
Talk to Computer 

FORTH, Inc. is working with Its parent 
company. Technology Industries, Inc. of 
Santa Clara, California, to develop a new 
software package for the Apple 11, using a 
ZaO processor. With it, the Apple will 
offer the kind of casual and efficient man- 
computer interface that until now, existod 
only in rnovies like 2001 and Star Wars. 

Tha project caUa for Savvy— tha trade 
name for Excallbur Technology Corpora- 
tion's Adaptive Pattern Recognition Pro- 
cessor—to be used as a unique language 
interpreter. Savvy permits a user to com- 
municate with a computer in the user's 
native language and normal proseology— no 
special language and forinm are needed. 
Specifically, "iavvy: 

o Recognizes written words strung 
tagetlwr In idiomatic ptvaaea. 
(Future versione will understand 
apoken words and respond to 
^snlsh eommwKto bs well as 
English. Other languages will 
folIowO 

o Translates these imprecise 
patterns Into precise computer 
commands. 

Savvy's unique interactive approach to 
dealing with computers is an important 
development for the 80s. The powerful 
combination of FORTH and Savvy will be 
significant In realizing the system's full 
potential and demonstrating the power of 
FORTH. A special development teem has 
been formed for this project, including Art 
Gravina, Chuck More, Dean SarKtorson, 
and another programmer who has not been 
identified. 
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